Full text of "Airport surface traffic control concept formulation study"

REPORT NO. FAA-RD-75-120.IV

AIRPORT SURFACE TRAFFIC CONTROL
CONCEPT FORMULATION STUDY

VOLUME IV - ESTIMATION OF REQUIREMENTS

: . D'ALESSANDRO
W. HEISER
G. KNIGHTS
P. MONTELEON
R. REFFELT
R. RUDMANN
W.WOLFF

raws*

DOCUMENT IS AVAILABLE TO THE PUBLIC
THROUGH THE NATIONAL TECHNICAL
INFORMATION SERVICE, SPRINGFIELD,
VIRGINIA 22161

Prepared for

U. S. DEPARTMENT OF TRANSPORTATION

FEDERAL AVIATION ADMINISTRATION

Systems Research and Development Service

Washington, D.C. 20591

NOTICE

This document is disseminated under the sponsorship
of the Department of Transportation in the interest
of information exchange. The United States Govern-
ment assumes no liability for its contents or use
thereof.

NOTICE

The United States Government does not endorse products
or manufacturers. Trade or manufacturers' names appear
herein solely because they are considered essential to the
object of this report.

Technical Keaort D.

^FAA-RD-75-120.IV

^AIRPORT SURFACE TRAFFIC CONTROL
CONCEPT FORMULATION STUDY
Volume IV - Estimation of Requirements

4. T.tl. and Sut

• Au or F. D'AIessandro, W. Heiser, G. Knights,
P. Monteleon, R. Reffelt, R. Rudmann, W. Wolff

■! 1

- 3 5556 029 297256
July 1975

6. P.rfofmmg Orgon, *ot.on Co(

9 P-.to-r-Mng G.gom.o-ion R.noM t>

DOT-TSC-FAA-75-8. IV

Computer Sciences Corporation*
6565 Arlington Boulevard
Falls Church, VA 22046

10. Work Un,t No (TRAIS)

FA321/R6134

II. Con.-oc. or Gronl IS

DOT-TSC-678

12. Sponsoring Agency Nome ond Address

U.S. Department of Transportation
Federal Aviation Administration
Systems Research and Development Service
Washington. DC 20591

Final Report

September 1973-February 1975

15. Su,

♦Under contract to: U. S. Department of Transportation
Transportation Systems Center, Kendall Square, Cambridge

This four volume report presents system concepts for use in semi- automated airport sur-
face traffic control at all positions in the tower cab of the major airports. The control
functions and data requirements of a Ramp Control System, a Ground Control System,
and a Local Control System are presented. The concept development process has been
based upon an extensive study of cab operations at O'Hare Airport. This effort has in-
cluded extensive delay analysis, study of communication tapes, and personal observations
of the widely- varying situations that are faced by tower controllers. Following the Opera-
tions Analysis effort, a detailed study of requirements was performed and is presented in
Volume IV of this report. This requirements effort provided an estimate of the perform-
ance requirements of a surveillance sensor that would be required in a TAGS (Tower
Automated Ground Surveillance) system for use in both good and poor visibility condi-
tions. Detailed studies were made of the complex type of conflicts to be solved by both
the Ground and Local Controllers and operational levels and densities were developed.
One particular TAGS system concept (employing an ATCRBS Trilateration Surveillance
Subsystem) is described in Volume I and an estimate is made of its deployment potential
at major airports. Backup material on this concept in the form of a working paper
is held by TSC. This working paper also includes synthetic digital display concepts
for the three systems which have been summarized in Volume I.

17. K. r words Airport delays, requirements
capacity analysis, communications, syn-
thetic displays, ATCRBS Trilateration,
deployment estimates

DOCUMENT IS AVAILABLE TO THE PUBLIC
THROUGH THE NATIONAL TECHNICAL
INFORMATION SERVICE. SPRINGFIELD.
VIRGINIA 22161

Unclassified

. Security Cln.,,'. [o

Unclassified

Form DOT F 1700.7 (8-72)

At tower-equipped airports, the controllers in the tower cab are
responsible for those aspects of Airport Surface Traffic Control
(ASTC) requiring centralized management: issuing clearances for
aircraft to land, taxi, or take off; establishing routing patterns
for arriving and departing aircraft on the runway/taxiway net-
work so as to minimize delays; sequencing aircraft movements
on runways and taxiways and at critical intersections to ensure
safety; and controlling the movements of service or emergency
vehicles on the airport surface. Because of the expertise of the
controllers and pilots, the ASTC system has worked well most
of the time. However, the unfortunate incidents at Chicago-O'Hare
(20 December 1972) and Boston-Logan (31 July 1973) have pointed
out certain deficiencies; e.g., the system's surveillance capability
when visibility is poor.

Initiated by the Federal Aviation Administration (FAA), the ASTC
program is in the process of implementing several near-term
system improvements. However, it is expected that these improve-
ments, while adequate for the 1970's, will not be adequate to meet
the more stringent long-term requirements of the 1980 's.

The approach which has been taken in the present study is to con-
centrate on the Nation's most active and, in one sense, most
mature airport; i.e., Chicago-O'Hare. In performing the study
at O'Hare, the cooperation of the Airport Traffic Control Tower,
the City of Chicago Department of Aviation, and the FAA Great
Lakes Region was essential to the success of the effort. Mr.
Paul S. Rempfer, of the Transportation Systems Center (TSC),
acted as technical monitor for the Government. In addition,
Messrs. Rempfer and L. Stevenson, also of TSC, performed the
theoretical analysis of local area capacity which is presented in
Section 5. 3. 3. 1 of Volume III.

Digitized by the Internet Archive

in 2012 with funding from

CARLI: Consortium of Academic and Research Libraries in Illinois

http://www.archive.org/details/airportsurfacetr04dale

TABLE OF CONTENTS - VOLUME IV

Section 1 - Introduction

Page
1-1

1.1

Objectives

1-1

1.2

Characteristics of Requirements

1-5

1.3

Methodology

1-8

1.3.1

General

1-8

1.3.2

System Response Time Considerations

1-10

Section 2

- Composite Airport Surface Traffic Control System Options

2-1

Section 3

- Development of a Ramp Control System (RCS) Concept

3-1

3.1

Introduction

3-1

3.2

Requirements Estimation

3-1

3.2.1

General

3-1

3.2.2

Functional Requirements

3-11

3.2.3

Description of Information Transfer for Individual Functions

3-20

3.2.4

Operational Requirements

3-46

3.3

Preliminary Description

3-53

3.3.1

Overall Characteristics

3-53

3.3.2

Data Requirements

3-56

3.3.3

Interface /Data Transfer Considerations

3-58

3.3.4

Display Considerations

3-61

3.4

Benefits Assessment

3-64

3.4.1

Flight Clearance Delivery Function

3-64

3.4.2

Maintain Outbound Ramp Q

3-65

3.4.3

Pushback Clearance

3-66

3.4.4

Interdeparture Conflict Management

3-66

3.4.5

Handoff to Ground Control Departure Q

3-67

3.4.6

Verify Gate Assignment

3-68

3.4.7

Monitor Inbound Ramp Q

3-69

3.4.8

Clear to Gate

3-69

3.4.9

Outbound -Inbound Conflict Management

3-70

3.4.10

Composite Benefits

3-71

Section 4

- Development of a Ground Control System (GCS) Concept

4-1

4.1

Introduction

4-1

4.2

Requirements Estimation

4-2

4.2.1

General

4-2

4.2.2

Functional Requirements and Operational Logic

4-2

TABLE OF CONTENTS - VOLUME IV (Continued)

4.2.3 Performance Requirements

4.2.4 Operational Requirements
4. 3 Module Description

4.3.1 Overall Characteristics

4.3.2 Interface Considerations
4. 4 Benefit Analysis

4. 4. 1 General

4.4.2 Workload Reduction

Page

4-9

4-30

4-33

4-35

4-37

Section 5 - Development of a Local Control System (LCS) Concept

5-1

5.1 Introduction

5. 2 Requirements Estimation

5.2.1 General

5.2.2 Functional Requirements and Operational Logic
5. 2. 3 Performance Requirements

5.2.4 Operational Requirements

5.3 Preliminary Module Description

5.3.1 Overall Characteristics

5.3.2 Interface Considerations

5.4 Benefits Analysis

5.4.1 Capacity Improvement and Delay Reduction

5.4.2 Safety Benefits

5. 4. 3 Workload Reduction

5-1

5-7

5-13

5-31

5-32

5-33

5-35

5-37

Section 6 - Related Support Concepts

6-1

6. 1 Automatic Gate Status Equipment (AGSE) Concept
6.1.1 Introduction

6. 1. 2 Information Requirements Estimation

6.1.3 Functional Flow Description

6. 1. 4 Operational Requirements

6.2 Standard Taxiway Routing Module
6.2.1 The Routing Communication Problem

6. 2. 2 Standard Taxiway Routing Considerations

6.2.3 STR Module Development Concepts

6.2.4 Functional Requirements Estimation

6-3
6-5

6-6
6-7

Section 7 - Summary of Sensor Performance Requirements

TABLE OF CONTENTS - VOLUME IV (Continued)

Page

Appendix A - Characteristics of the Taxiway Network at O'Hare A-l

Appendix B - Aircraft Movement Profile Characteristics B-l

Appendix C - Link/Node Occupancy Considerations C-l

Appendix D - Movement Detection D-l

Appendix E - Prediction Errors E-l

Appendix F - Aircraft Movement Profile Characteristics for Runway/

Taxiway Crossing Control F-l

LIST OF ILLUSTRATIONS - VOLUME IV

Figure Page

1-1 Information Flow Between Major Components of Airport

Surface Traffic Control System 1-9
3-1 Ramp Area/ Terminal Configuration - O'Hare International

Airport 3-5

3-2 Positive Ramp Control Areas - O'Hare International Airport 3-7

3-3 Possible Data Base Organization Concept for Ramp Control

System 3-17

3-4 Flight Clearance Delivery - Functional Flow Diagram 3-21

3-5 Maintain Outbound Ramp Queue - Functional Flow Diagram 3-24

3-6 Pushback Clearance - Functional Flow Diagram 3-26

3-7 Interdeparture Conflict Management - Functional Flow Diagram 3-27

3-8 Example of Possible Ramp Area Congestion Problem 3-31

3-9 Handoff to Ground Control Departure Queue - Functional Flow

Diagram 3-34

3-10 Verify Gate Assignment - Functional Flow Diagram 3-36

3-11 Monitor Inbound Ramp Queue - Functional Flow Diagram 3-38

3-12 Clear to Gate - Functional Flow Diagram 3-40

3-13 Outbound -Inbound Conflict Management - Functional Flow

Diagram 3-42

3-14 Ramp Control System Functional Configuration 3-54

4-1 Operational Logic for Ground Control System (GCS) Function 4-8

4-2 Logic Flow Diagram for Release of Departures into Taxiway

System (Function A) 4-12
4-3 Logic Flow Diagram for Entry of Arrival Aircraft (Functions

C and D) 4-16
4-4 Logic Flow Diagram Penalty Box/Staging Area Management

(Function E) 4-21
4-5 Logic Flow Diagram for Interface/Handoff to Ramp Control

(Function F) 4-22

4-6 Logic Flow Diagram for Routing Control (Function G) 4-25

4-7 GCS Module 4-34

5-1 Arrivals on Intersecting Runways 5-4

5-2 Arrival/Departure Sequencing Mixed Operations on Same

Runway 5-4

5-3 Typical Taxiway /Runway Crossings 5-5

5-4 Arrival/Departure Sequencing Separate Crossing Runways 5-5

5-5 Preliminary Functional Logic For Local Control System 5-12

5-6 Intersecting Runway Configurations 5-28

5-7 Major Componsnets of Semi-Automated Local Control

System (LCS) 5-34

LIST OF ILLUSTRATIONS - VOLUME IV (Continued)

Page

Functional Flow for AGSE in Airports Without Positive

Ramp Control 6-4

Initial Routing Sequence of Inbound and Outbound Ground 6-8

LIST OF TABLES - VOLUME IV

fable Page

1-1 Identification of Potential System Users 1-6

1-2 Pilot Functions 1-10

3-1 Ramp Control System - Functions and Requirements 3-14

3-2 Potential Maximum and Minimum Inbound Delays for N

Outbounds in the Ramp Area 3-33
3-3 Summary of Estimated Ramp Congestion Delays at O'Hare

International Airport 3-49
3-4 Summary of Data Requirements for Ramp Control System

Functions 3-57
3-5 Summary of Proposed Data Contents of Primary Ramp Control

System Working Files 3-59
3-6 Summary of Data Display for Flight Operations Control

Functions of Ramp Control System 3-63

4-1 Ground Control System Functions and Requirements 4-5

4-2 Summary of Conflict Types (Ground Control System) 4-27

4-3 Functional Activity Comparison - Present and GCS Approaches 4-38

5-1 Aircraft Movement Profile Data (Local Control System)

(Based primarily on air carrier jet aircraft) 5-3

5-2 Control Functions and Requirements Local Control System 5-9

5-3 Summary of Potential Single R/W Conflicts and Information

Requirements 5-22
5-4 Summary of Potential Intersecting R/W Conflicts and

Information Requirements 5-30
5-5 Functional Activity Comparison - Present and LCS Approaches 5-38

6-1 Route Selection Parameters 6-11

SECTION 1 - INTRODUCTION

1.1 OBJECTIVES

General criteria for an ASTC system include (1) to be as simple and
low in cost as possible while addressing the basic objectives and (2) to be equally
applicable to all airports requiring it, which could be quite a few. The basic
system objectives fall into three major areas of control as follows:

1. Local Control - To provide accurate and timely information to
Local Control on the suitability of each inter-arrival space for

a departure release. This assistance would offer benefits which
could amount to a 20 percent increase in departure capacity for
the more difficult to handle runway configurations with good
visibility and a 30 percent increase for single mixed operations
with bad cab visibility. Also, Local Control must be provided
with positive assurance that the runway on which he is about to
clear an operation is, in fact, clear of other vehicles. This
latter requirement is critical to the basic safety of operation.

2. Ground Control - To provide the location and identity of each
vehicle under control to Ground Control to reduce the excessive
communications (work) load due to position reporting under bad
visibility conditions. The average content of voice communi-
cations for Ground Control, indicates that these position reports
represent 85 percent of the increased channel loading experienced
under bad cab visibility. The identity could assist Ground Control
in maintaining vehicle/identity correlation in good visibility.

3. Ramp Control - To provide a centralized system of ramp entry
clearance to permit the most efficient use of those ramp areas
which can only support one-way traffic flow. This implies
operation in a batch or platoon mode (e.g. , multiple "pushbacks"
and taxiing aircraft within a ramp area).

The first two objectives are basically information presentation (sur-
veillance) problems. In light of criteria (1), the initial ASTC concept will be
surveillance only, without control automation. In addition, automation of control
functions would make it much more difficult to maintain equipment commonality
between airports. While the basic information needs at different airports may be

the same, the control problems, especially for an automated Ground Control
System, can be quite different.

The third problem is quite different from the first two. There is
currently no centralized ramp control. The FAA is not responsible for the ramp
area; there is no such control position. Staffing constraints and room in the cab
make addition of a position undesirable. Such a system would have to be heavily
automated and managed by the current complement of controllers, primarily
Clearance Delivery. This automation would probably require the substantial
tailoring of equipment to each airport. In addition, the participation of airline
operations personnel would be required in the system and scheduling of pushbacks
(a controversial item at best) would be involved.

The above considerations motivate the Tower Automated Ground
Surveillance (TAGS) concept. TAGS is basically a surveillance system aimed at
problems 1 and 2 above. Information retrieval, processing, formatting and
display are automated. Control functions remain in the hands of the controllers.
It is a simple system (conceptually), addressing the basic problems and permitting
inter-airport equipment commonality. In the remainder of the report TAGS is
described in terms of subsystems covering its major areas; a Local Control
System (LCS) and a Ground Control System (GCS). In addition, to provide an
understanding of what could be offered in the ramps, a Ramp Control System (RCS)
is also described. Because of the problems enumerated above, RCS is considered
an option and is not intended as part of the initial TAGS development.

The results of this working paper are expected to be used in the further
development of concepts for each of the three major systems. Preliminary discus-
sions of the system concepts are provided in this document in order to show how
the requirements are related to the concept currently under development. It is

expected that refinements to the requirements established in this working paper
will take place as they are compared with the capabilities that can be achieved
through various surveillance sensor techniques and/or data transfer methods. As
such, therefore, they should be taken as representing a "first cut" in establishing
the information required by the controller and the estimated performance require-
ments of the surveillance sensors that will serve to collect this information.

In performing this concept development, the system designer is faced
with the problem of attempting to replace the information gathering capabilities of
a visual surveillance method with other display or information presentation methods
wherein the man/machine information transfer process will be completely different
from that provided by visual means. Because of this, the design philosophy employed
in the concept development process has been one wherein emphasis is placed on the
use of data processing techniques as far as possible to perform as many portions of
the control functions as possible; the basic premise, however, is that the control
decisions will be made by the controller and not by the machine. Under this philos-
ophy emphasis is placed upon the real-time, semi-automatic aspects of the control
process wherein the information presented to the controller is specifically related
to the function he is performing at a given time. Without this selectivity, it is be-
lieved that the controller's ability to perform the required functions at normal op-
erational levels will be seriously hampered.

Another common aspect of the three portions of the ASTC system would
be the use of data processing capabilities for controller cueing, or scheduling, of the
functions he is to perform. This capability, of course, would be overridden by the
controller when necessary.

The methodology employed to establish the several types of require-
ments is discussed later in this section; it essentially relies on the examination of
aircraft movement profiles and the control actions currently employed by the cab
controllers. The functions performed in each of the three major systems have been
derived as a result of careful and extensive study of cab operations at the busiest

commercial airport in the world, namely, O'Hare Field. It is recognized that at
some other major airports all of the functions described in this report may not be
necessary, and that in some cases other functions may be required. However, in
our judgment these changes will be minor.

For each of the three systems the functions to be performed are de-
scribed. The information transfer aspects of each function are examined and these
are then translated into the performance requirements desired of the surveillance
sensors. To determine the total load on the three systems, airport operational
levels are estimated both during the busy hour as well as for short-term peaks.
This operational requirement will impact on the data rates at various portions of
the several systems and will, for example, be used in establishing surveillance
sensor update rates, "refresh" rates of displays, etc.

A basic constraint used in the development of the three systems has
been the reliance on voice rather than data link between the pilot and the controller.
The availability of automated communications between these two individuals can, in
the future, lead to the evoluation of a more fully automated system from the con-
cepts presented in this and subsequent documents.

In addition to investigating the three major systems described above,
further material is presented on two other concepts which will impact on the Ramp
Control System and Ground Control System, respectively. In the first area an
Automatic Gate Status Equipment is included as part of the Ramp Control System.
This subsystem could be expected to provide benefits to the airline operators by
itself, and at some airports may be desirable as a separate module even though an
automated or semi-automated Ramp Control System is not implemented.

With respect to the control functions performed as part of the GCS, a
separate examination was made of potential benefits of a so-called STR (standard
taxiway routing) module. This particular aspect is treated separately from the
Ground Control System which, of course, does include as one of its functions that
of Routing Control.

1.2 CHARACTERISTICS OF REQUIREMENTS

The establishment of system requirements is a complex process involv-
ing tradeoffs between design concepts, economics, and operational constraints.
The conventional starting point is usually that of defining the problem(s) by means
of a series of data collection experiments, or operations analysis. While many
valuable inputs to the requirements establishment process are obtained in this
manner, it should be recognized that an existing system or procedure in itself
imposes constraints or limitations which a new system concept may not have to
contend with.

The requirements to be set forth in this document are preliminary in
nature; it is expected that system (module) synthesis efforts to be performed later
in this program will result in some modification to the qualitative and quantitative
values given in this report. We shall consider requirements as comprising three
areas, namely Functional, Operational, and Performance requirements as defined
below.

Functional requirements may be defined as those describing the tasks
which a system or module is to accomplish. They answer the question 'What must
the system do?" and as such are a mixture of qualitative and quantitative state-
ments. Representative examples of functional requirements include:

• Release of an aircraft for takeoff (or taxiing}

• Clearance for runway crossing

• Providing route information

Identification of system (subsystem) users and their characteristics
will also be considered as part of the Functional Requirements definition. In most
cases the primary users of the system are the controller (s) and the pilots; however,
other potential users (or data sources) will be involved in the information flow proc-
ess. A preliminary list of potential system users and/or personnel who may inter-
face with the TAGS system is given in Table 1-1.

Table 1-1. Identification of Potential System Users

FAA - CAB

Flight Data

Clearance Delivery

Outbound Ground Control

Inbound Ground Control

North Local Control

South Local Control

Watch Supervisor

TRACON

Approach Control - North

Approach Control - South

Departure Control - North

Departure Control - South

Monitor Control

Airlines

Pilot

Personnel

Ramp Area

Gate Attendant

Cargo Supervisor

Tow Vehicle Operator

Ramp Supervisor (Gate Manager)

Ramp Controller (Tower)

Airport

Vehicle Operator

Duty Supervisor

To meet the Functional Requirements, the subsystem work flow may-
be considered as comprising machine-type process and human efforts. We shall
attempt to use the term "job" to describe machine-type process and the term
"task" to describe those functions performed by the controller, pilot, etc. Pre-
sentation of data, via a display, to the controller is therefore a "job" of the partic-
ular subsystem, while the interpretation of this data, as well as the voice commun-
ication process represent "tasks" performed by the controller.

Operational requirements represent parameters relating to the total
situation under which the functional requirements are to be met. They include
traffic considerations (load); environmental (weather) aspects; facility constraints
(runway configurations, ramp areas, etc. ); and the operational procedures and
standards imposed for safety reasons. Representative examples of operational
requirements include:

• Number of active aircraft in a particular geographic area at one
time or during a particular interval of time

• Visibility level

• Separation standards

Performance requirements are a quantitative estimate of the acceptable
capabilities of the module and its components required to meet the applicable func-
tional and operational requirements. These are expected to vary in different por-
tions of the TAGS system, i. e. , the required position accuracy may be different
in the ramp area as contrasted with the final approach area. Typical examples of
performance requirements include:

• Data Rates /Response Times

• Accuracy of Position and/or Velocity Data

• Resolution

1.3 METHODOLOGY

1.3. 1 General

The methodology employed to develop the ASTC (TAGS) performance
requirements has been based upon a detailed examination of mission profiles (or
scenarios). These scenarios are comprised of three major components, namely

Aircraft Movement Profile

Pilot Functions

Control System Functions

The information flow between the major components of the ASTC sys-
tem is illustrated in Figure 1-1; the characteristics of these components will, of
course, be different for the Ramp Control, Ground Control, and Local Control

Systems.

The Aircraft Movement Profile component includes both aircraft pa-
rameters/constraints, as well as airfield/airspace characteristics. As represen-
tative of the former, one must consider aircraft equipment types, braking capabili-
ties, etc.; the latter area essentially describes the characteristics of the facilities
(taxiways, runways, etc. ) that can be considered as providing "service" to the air-
craft.

Functions expected to be performed by the pilot in the semi- automated
system are listed in Table 1-2. These functions are relatively independent of the
particular control system involved.

The Control Functions will be examined in detail for each of the three
major subsystems. This investigation will consider first the estimated Data Re-
quirements needed either by the Controller or a computer to adequately perform
the Control System Functions. It is in this area that consideration must ultimately
be given to man/machine interface or display characteristics.

Table 1-2. Pilot Functions

Maintain separation from preceding aircraft on
same link or "highway".

Determine partial identity (aircraft equipment type
and airline) of nearby aircraft.

Maintain aircraft speed below safe limits consistent
with taxi way constraints and flight phase.

Navigate aircraft using VGE references and aircraft
instruments.

Maintain lateral (center line) control.

Select appropriate R/W turnoff.

Stop aircraft clear of intersections, obey runway
crossing hold lines.

Provide controller with aircraft status data as needed
i.e., Ready-to-Taxi, Position Report, etc.

Inputs to the system Data Base — from which the control data is de-
rived — will be classified as Information Elements. These fall into two classes:
Real Time (or sensor-derived) data and Support data. The characteristics of the
required Sensor or Real Time Information Elements are those of primary interest.

The communication processes for a semi-automated system may use
present-day voice techniques or signaling methods which, for example, utilize
FGE facilities, or possibly existing capabilities in the cockpit. Of major interest
insofar as the communications portion of the control process is concerned is the
System Response Time discussed in the next paragraph.

1.3.2

System Response Time Considerations

The major response time factors to be considered for a semi-auto-
mated surface traffic control system include

Sensor Response Time Variable

Conflict Recognition (Detection) Interval 1.5-3 sec.

Conflict Resolution Time 1-2 sec.

Communication Duration (Controller-Pilot) 5-6 sec.

Aircraft Dynamics (including Pilot Response Time) 5. 5-8 sec.

Preliminary values have been assigned to these various components of
response time based upon rationale given below.

The Conflict Recognition process would be performed by a computer
with negligible time delay. However, presentation of the results to the controller
via some type of display, plus his interpretation of the display, will take a small
amount of time. Moreover, it is expected that multiple conflicts may result in de-
lay in the presentation of a small number of cases. These factors had led to an
estimate of from 1. 5 seconds to 3 seconds for this process.

The Conflict Resolution process is that wherein the Controller makes
the decision to prevent the upcoming conflict. This decision, which may involve
holding or sequencing an aircraft, may overlap the Conflict Recognition process.
Time estimates of 1 second to 2 seconds have been used for this process.

Communications transactions (CT) between pilots and controllers aver-
age about 8 seconds to 9 seconds in duration. Control or decision-type CTs are
expected to be shorter. Based upon voice communications this parameter has been
estimated at from 5 seconds to 6 seconds.

The implementation by the pilot of a control instruction will be con-
strained by the pilot response time (0. 5 second to 1. second) as well as the dynam-
ics of the aircraft. At normal taxiing speeds it is estimated that 5 seconds to 7
seconds may be required for a normal aircraft "stop".

The sum of the above factors ranges from 13 seconds to 19 seconds.
Sensor response times of from 1 second to 2 seconds represent durations which
would not unduly penalize the overall system response time. This range of

intervals permits the recognition of the various events to be handled in the control
process, i. e. , recognition of the time an aircraft enters the taxi system or new
link.

These components of response time require of course further study of
man/machine relationships in the actual system and represent, therefore, only
very preliminary values. The limiting factors of voice communications and air-
craft dynamics are readily apparent in the breakdown given above.

It is envisioned that the conflict estimation process to be performed by
the computer would be organized so that several levels of potential conflict are de-
fined based upon the prediction interval. For example, top priority would be given
to prediction intervals of say 15 seconds to 22. 5 seconds, second priority to con-
flicts expected to occur in time intervals of 22. 5 seconds to 30 seconds in the future
and lowest priority to a time interval of 30 seconds to 45 seconds. An example of
the latter might be the prediction of an "Arrival" at the ramp entrance point.

SECTION 2 - COMPOSITE AIRPORT SURFACE TRAFFIC
CONTROL SYSTEM OPTIONS

The integration of the three major systems into a composite ASTC
system for a specific airport can result in a wide variety of hardware config-
urations. These configurations will be influenced by the airport layout, capa-
bilities of existing hardware, weather considerations, etc. In some cases, it
may be desirable to provde semi-automation capabilities for only some of the
functions performed in one of the three major areas. For example, a subsys-
tem providing R/W crossing management might be a desirable feature at an
airport having visibility constraints but not requiring automation of other Ground
Control functions. It is not the purpose of this document to put together all the
possible means by which composite ASTC systems can be designed for a spe-
cific airport from the building blocks or systems described herein. The rationale
by which the performance requirements are developed for each of the three sys-
tems can be used by the system designer to tailor a particular configuration
meeting the needs of a specific airport. Later in this report a composite list
of system performance requirements is developed based upon those established
for each of the three separate systems. In some cases, therefore, only the
performance requirements needed for one of the three systems might have to
be specified for a given installation.

It is expected as more detailed design of the total ASTC concept is
accomplished, specific recommendations for utilizing existing data processing
hardware, centralizing data bases, etc. can be developed. These interface
and specific airport- related aspects of the ASTC design are beyond the scope
of the current study.

SECTION 3 - DEVELOPMENT OF A RAMP CONTROL
SYSTEM (RCS) CONCEPT )

3. 1 INTRODUCTION

This section investigates the possibility of an automated Ramp Control
System. It is intended to show what might be done in the ramp area. As stated in
the introduction, RCS is considered an optional subsystem of TAGS and will not be
a part of the initial TAGS development.

The development of the Ramp Control System (RCS) (module) concept
is directed toward improvement of the processes for coordination and control of
operations in the ramp area(s) of the airport and for coordination of these opera-
tions with other airport surface traffic control operations. The development of the
concept is based upon the integration of:

traffic control tower (ATCT), airline operations, and automated
enroute and terminal ATC systems.

e Established basic procedures for flight operations coordination.

» Extension of positive control of flight operations to those ramp

areas which justify such control.

operations management, and display of cue information to tower
personnel.

3.2 REQUIREMENTS ESTIMATION

3.2.1 General

The RCS conceptual design incorporates the functional tasks associated
with air traffic operations within or related to the airport ramp areas. This includes
those functions now being performed by ATCT and airlines operations personnel as
well as those additional functions necessary to more effectively and efficiently
accomplish the specific performance objectives of the module.

These objectives include:

• To accomplish all information transfer related to acquisition,
maintenance, and presentation of data for initiation of service
to flight operations within the airport ramp areas.

• To accomplish all information transfer related to coordination

of flight operations within the ramp area(s) and between the ramp
area(s) and the airport taxiway network.

• To achieve an orderly flow of aircraft traffic within the ramp
area that affords an optimum balance between delays (when
necessary) to outbound and inbound traffic.

The areas of service of the RCS include all ramp areas associated with
the airport passenger terminal (s), cargo terminal, and hangar facilities. To ac-
complish the necessary services within these areas the module must achieve opera-
tional interfaces between the ATCT and airline operations, NAS enroute system,
and ARTS III. The system (module) must also achieve operational interfaces with
other ASTC system modules, i.e. , Ground Control System (GCS) and Local Control
System (LCS). The interface with the Ground Control System is of primary impor-
tance because of the physical interface between the ramp area(s) and taxiway net-
work and the requirement to coordinate the management of traffic operations at
these physical interface points.

The Ramp Control System concepts described here represent, to a
significant degree, modification of current procedures in airport surface opera-
tions. These concepts are dependent upon two underlying or subsidiary concepts
and a number of assumptions regarding the manner of operations in the ramp areas.
These subsidiary concepts are those of Positive Ramp Control and Gate Schedules
Data Maintenance.

3. 2. 1. 1 Definition of Positive Ramp Control

An essential element of the development of the RCS concept is the sub-
sidiary concept of Positive Ramp Control.

In current operations at most airports, air carrier traffic may initiate
their pushback when it is determined to be feasible by the aircraft crew and airline

ramp operations and ground crew personnel. * Where the physical characteristics
of the ramp area/terminal building configuration permit free movement of aircraft
around another aircraft, this mode of operation does not cause any operational dif-
ficulties. However, where the physical characteristics of the ramp area/terminal
building configuration does not permit this free movement, then significant opera-
tional difficulties may occur. For departures, this occurs when a flight which is
ready to taxi cannot do so because of the pushback of another aircraft from a gate
ahead of the first aircraft's gate. When this situation occurs, the delay may also
result in the need for the ground controller to resequence the flight into the traffic
stream. For arrivals, delays occur when the flight cannot enter the ramp area and
taxi to its gate because its way is blocked by a departure taxiing out of the area or
in pushback ahead of the arrival's destination gate. When this situation occurs, the
ground controller may have to hold the arrival on the taxiway until the blockage is
cleared, possibly resulting in delays to other aircraft following it or, to avoid
such delays, issue instructions for additional taxiing of the arrival.

At some airports where this ramp constriction situation exists, indi-
vidual airlines have constructed their own tower facilities (e. g. , United Airlines
and American Airlines at O'Hare) to afford their ramp controllers visual surveil-
lance of the ramp areas in which they operate. This permits the ramp controller
to determine when departure pushback should be delayed to avoid interference with
their other flight operations or to avoid conflicts with the operations of other air-
lines sharing the same ramp area.

Even with these more advanced airline operations, and certainly where
such facilities are not employed, the occurrence of delays to outbound as well as
inbound flights is quite frequent. While ramp controllers can exercise management

*At some airports, flights operating at certain gates must obtain pushback clearance
from the tower when pushback from their gates would temporarily block passage of
other aircraft on the taxiway network (e.g. , Continental Airlines operations on gates
D-ll and D-12 at O'Hare International Airport).

of their own operations, they cannot directly exercise control of the operations of
other airlines. Thus, another airline's flight may push back and block an outbound
or inbound flight. At O'Hare, United and TWA have discussed the possibility of
United providing pushback control of TWA flights. However, for several reasons
no agreement was reached. The major deterrent was that the United tower afforded
visibility of only the F-G ramp area which they share but not the G-H area in which
TWA also operates, as shown in Figure 3-1.

The objective of the concept of Positive Ramp Control is to achieve
and improve on the capabilities provided by the individual airline ramp control
tower and to extend these capabilities to all ramp areas where it is required.
At any given airport, the ramp area/terminal building configuration may incorpo-
rate areas in which Positive Ramp Control is not required and those in which it is.
Those areas in which such control is deemed necessary are (and will be) referred
to as Positive Ramp Control areas. The extent to which Positive Ramp Control is
required will obviously vary from airport to airport. At airports such as O'Hare,
LaGuardia, Los Angeles, and Atlanta, Positive Ramp Control may be the predomi-
nant mode of operation with some areas not under Positive Ramp Control At
airports such as Logan, Kennedy, Philadelphia, and Newark, Positive Ramp
Control may be a minor mode of operation for only one or two areas. At many
other airports such as Cleveland, Dallas-Ft. Worth, San Francisco, and Bal-
timore, Positive Ramp Control may not be needed at all.

Thus, at each airport those ramp areas which will require Positive
Ramp Control would have to be identified. These would include all areas in which:

• The outbound taxi of a departure flight (or aircraft moving from a
terminal gate to another airport location) could be blocked by push-
back of another aircraft

• The inbound taxi of an arrival flight (or aircraft moving to a termi-
nal gate from another airport location) to its gate could be blocked
by pushback of a departure flight

LEGEND

• Je

way

A Stc

irs

d Sta

rs ond

Lowe.

Jelway

■ Ab

revial

d Jetu

LL Lo

xer Le

Airline

Tower

Figure 3-1. Ramp Area/Terminal Configuration -
O'Hare International Airport

• The available space would permit simultaneous taxi (and passage)
by two outbound aircraft or by both outbound and inbound aircraft
under good visibility conditions but where this cannot be accom-
plished with a sufficient degree of safety when pilot visibility is
impaired under poor weather conditions.

The application of these criteria to O'Hare for the passenger terminal
ramp area is illustrated in Figure 3-2. The C-D, D-E, F-G, and G-H ramp areas
are obvious candidates for Positive Ramp Control areas. The area to the east of
K-wing is a candidate for Positive Ramp Control because the presence of blast
fence limits the space available for aircraft movement. Moreover, based upon the
airport management's indicated anticipation of construction of an L-wing in the
future, this area would probably remain a candidate for Positive Ramp Control.
The area to the north of the B-wing is not currently estimated to require Positive
Ramp Control even with the presence of general aviation traffic at the Butler ramp.
However, with the airport management's anticipated future construction of an
A -wing (and a new general aviation terminal), Positive Ramp Control for this area
may become necessary.

Therefore, the concept of the Ramp Control System provides for in-
corporation of Positive Ramp Control and non-Positive Ramp Control modes of
operation for departure and arrival aircraft as a function of the origination/desti-
nation gate of the aircraft. Positive Ramp Control in designated areas would be
applied to both normal aircraft departure/arrival flights as well as to flights mov-
ing between these areas and terminal facilities (i.e. , cargo and hangar areas).
Depending on the configuration of the airport cargo and hangar areas, these areas
could also come under Positive Ramp Control.

As noted earlier, the concept of Positive Ramp Control is to improve
on and extend the capabilities now achieved by the individual airline control tower.
A number of approaches were considered in developing the Ramp Control System
concepts described in this section. These included:

AIRLINES

\/7 AAL

American

EAL

Eastern

yy Ac

Air Conada

NOR

North Central

Jf AL

Allegheny

NWA

North West Orient

7 BNF

Broniff

OZA

Ozark

r CAL

Continental

TWA

Trans WorlO

DAL

Delta

UAL

United

Blast Fence

Figure 3-2. Positive Ramp Control Areas ■
O'Hare International Airport

1. Provision of Positive Ramp Control through the airlines with each
airline provided with sufficient capability to control its own flights
in relation to other flights operating in the same ramp area.

2. Provision of Positive Ramp Control through the airlines but where
these responsibilities would be exercised by one or more airlines
serving their own and other airlines' flights.

3. Provision of Positive Ramp Control by FA A personnel operating
in suitable locations, such as existing airline towers.

4. Provision of centralized Positive Ramp Control by FAA personnel
operating in a single location, i.e., the ATCT.

Each of these approaches has certain merits and disadvantages. At
O'Hare, for example, the American and United towers could be readily used to
provide control in the D-E, E-F, F-G, G-H, H-K, and K positive ramp areas
within approaches 2 and 3 above. However, these locations are not adequate for
control of the B-C and C-E Positive Ramp Control areas. It is recognized that an
additional facility could be constructed to serve these areas or, in the case of 3_
above, this could be accomplished from the ATCT.

After due consideration, approach 4 above was adopted as a preliminary
approach. The primary factors in this determination included the following:

1. It is applicable to all airport configurations independent of the
availability of airline control towers or other suitable locations.

2. Agreements between airlines over control of each other's operation
may be potentially difficult to achieve.

3. Centralization of all required information, information processing,
and display of conflicts at a single location for decision making
appears more practical, both operationally and technically.

4. Vesting of control authority in a non-airline position would avoid
potential disagreements over favoritism and provide more objec-
tive ramp area management.

Thus, it has been assumed the Positive Ramp Control as well as other
functional responsibilities of the Ramp Control System would be exercised by the
ATCT through Ramp Control positions. The extent to which these responsibilities
could be exercised through expansion of the role of the existing Clearance Delivery
position or would require an additional position in the ATCT would be determined
by the volume of traffic and the degree of Positive Ramp Control required in pro-
portion to other Ramp Control System operations. In either case the exercise
of these functions will require data exchange with the airlines as discussed in the
following section.

3. 2. 1. 2 Gate Schedules Data Maintenance

The second subsidiary concept within the development of the Ramp Con-
trol System concept is the maintenance and application of gate schedules data. This
concept is important for several reasons. First, knowledge of the ramp location
(gate) from which a flight is departing or for which a flight is arriving will deter-
mine whether it will come under Positive Ramp Control. Second, knowledge of the
ramp location of a departure is necessary for the ASTC system functions of routing
to the runway, sequencing the flight in the taxi flow pattern, and determination of
conflicts with arrival aircraft for the same ramp. Third, knowledge of the desti-
nation gate for arrivals and the availability of the gate is necessary for routing of
the flight by ground control operations.

Currently, origination gate, destination gate, and availability are de-
termined by direct communications between the ATCT and the flight. The objec-
tive of this subsidiary concept is to obtain and maintain this data in a more timely
and efficient manner in order to reduce controller and pilot communications work-
load and more effectively manage system operations.

Discussions with airlines personnel during the preceding O'Hare Opera-
tions Analysis indicated that preplanned gate schedules are developed whenever
major rescheduling of flight operations occurs. Temporary adjustments to these

schedules are made when special flights are added to their schedule or when gate
changes are necessitated by the operational situation (delays, equipment changes,
etc . ) .

The concept incorporated here is based upon storage of the preplanned
gate schedules in the Airport Surface Traffic Control (ASTC) system data base for
reference by the Ramp Control System. This data base would be updated when
temporary adjustments are made through direct communications with the airlines'
flight operations. To maximize the efficiency of these communications it is antici-
pated that digital data transfer between flight operations and the ASTC system would
be accomplished through suitable terminal devices (Automated Gate Status Equip-
ment) in the airline flight operations facilities.

The concept further provides that this gate schedule data base be
maintained on a dynamic basis by the internal processing of the Ramp Control
System. The purpose of this is to maintain a reference of the current status of
occupancy of gates (e. g. , open, occupied, aircraft off gate but not yet departed).
This information would be employed by the Ground Control System in determining
whether an arrival can be routed directly to its gate or must be routed to an interim
holding area (e.g. , O'Hare's Penalty Box).

One of the basic requirements of this subsidiary concept as well as
that of Positive Ramp Control is a positive data entry that the aircraft has docked
or parked at its gate.

It is fully recognized that this concept, involving direct operational
interface between proposed RCS and airline flight operations, is new to airport
operations and that its implementation will require acceptance by the airlines.
However, substantial benefits to both airline, ATC, and airport operations should
result.

3.2.1.3 Basic Assumptions

The RCS concepts described here were developed to be generally appli-
cable to a broad range of environments at major airports. The concepts provide
for airport configurations including both positive and non-positive ramp areas as
well as a mix of IFR and VFR traffic. To satisfy this objective, several assump-
tions were made relative to the nature of the ramp control services provided and
to traffic procedures within the ramp areas. These assumptions are:

• Control of flight movements from/to/within the ramp area will
be accomplished primarily as a scheduling function

• No real-time sensor surveillance for control of aircraft lineal
(forward) and lateral (turning) movements will be performed

• No real-time guidance of aircraft lateral (turning) maneuvers
will be provided

• Departure flights or flights to cargo/hangar areas will remain
in pushback position until receipt of positive clearance to taxi
from Ground Control; i.e., they will not move toward the outer
edge of ramp area while waiting for such clearance

• Where sufficient ramp surface exists for an aircraft to hold (off
the taxiway network) while waiting for the ramp to clear for taxi
to its gate, Ground Control may clear a flight off the taxiways to
the ramp area with instructions to "monitor Ramp Control". The
flight would remain in the holding position until cleared by Ramp
Control for taxi to its gate.

3.2.2 Functional Requirements

The major functions to be performed by the Ramp Control System have
been derived from the detailed study of existing ASTC system procedures and flight
operations during the period of service within the ramp areas. These functions are
for the most part defined for implementation employing semi-automated control
techniques to improve system effectiveness and efficiency. No provision for auto-
mated transmission of data to aircraft flight deck has been considered. Therefore,
transmission of clearances, control instructions to aircraft, and pilot reports of

flight status are by voice radio. Further improvements in the concepts outlined
herein could be achieved in the future with the introduction of data links or by
DABS.

3.2.2.1 Identification of Control Functions

The RCS functions may be divided into three categories, based upon
whether they are required for departures (outbound) or arrival (inbound) flights
or are common to both. These functions include:

Departures

A. Flight Clearance Delivery

B . Maintain Outbound Ramp Q

C. Pushback Clearance

D. Inter-Departure Conflict Management

E. Handoff to Ground Control Departure Q

Arrivals

F. Verify Gate Assignment

G. Monitor Inbound Ramp Q
H. Clear to Gate

Common

J. Outbound/Inbound Conflict Management

Each of these functions is examined in order to determine the informa-
tion needed for data processing and decision making by the system computer equip-
ment, controller, or airlines operations to perform the appropriate job (or task).
There is a substantial amount of interaction between many of these functions. For
example, Function C requires that: (1) Function A has been accomplished; (2)
Function D (no conflict with other departures in the same ramp area) is satisfied;
and (3) Function J (no conflict with inbound flights to the same ramp area) is satis-
fied. However, Function J also requires that Function G has been accomplished.

As another example, in current operating procedures the equivalent of
Function E is accomplished as soon as a flight indicates it is ready to taxi. *
Ground Control may contact the flight immediately for taxi or may delay contact
because of other operational demands (e.g. , another departure in the same ramp
area which must taxi out first). Even after contact is established, compliance
with Ground Control instructions could be blocked by the actions of another out-
bound or inbound flight. For the proposed RCS concept, Function E would be
accomplished only when potential conflicts with the movement of the aircraft have
been determined not to exist or have been resolved and, therefore, that the flight
may move without delay when contacted by Ground Control. In effect, then, this
function reserves the ramp area between the region of the departure's gate and
the ramp/ taxi way interface point for its exclusive movement.

Table 3-1 lists the major functions required in the Ramp Control Sys-
tem (module). The second column identifies where interface is required with the
Ground Control and Local Control Systems, with airline flight operations, and with
the NAS enroute and ARTS III systems. The third column lists (in order) the sequence
of events or interacting functions which must be recognized or performed in accom-
plishing the function. In the case of Function D, Inter-Departure Conflict Manage-
ment, the table shows an interaction with Functions B and C at the start of the se-
quence. These are essentially requests for the performance of Function D. How-
ever, if an inter-departure conflict is determined to exist, the sequence will return
to the initiating functions. The return is not specifically indicated to avoid redun-
dant listing of the interacting function. The same is true for Function J, Outbound-
Inbound Conflict Management, in relation to Functions D and G. Where applicable
the entries in this column have been classified as "Demand", "Start of Service",
or "End of Service". These terms are intended to identify the entry of a demand

*Assuming that gate hold procedures have not been put into effect because of ex-
tensive operational delays.

u. S"

lie

Pushback clearance granted when Functions D
and J requirements are satisfied

Flight may be cleared to pushback "when
previously conflicting fhght is past."

■I'-
ll

i .s
ill

111

s a
II

E S

I
f I

< i,

lil

EoD.2

5 &

f I

9 1
} J

1
&

I .2

1 3
g-,3
'is E

JfJ

Receipt of Fhght Clearance From ARTCC (For IFR Deps)

Receipt of Call From Pilot (Start of Service)

Issue Flight Clearance

Function B

Function F (VFR Dep)

Pilot CaU-Ready to Taxi (Concurrent with Function A

for VFR) (Demand)
Function C

Establish/Update Q Ust
Function D
Function J

Receipt of Call for Clearance to Pushback (Demand)
Update Q Ust
Function D

Issue Pushback Clearance/Hold
Function B

1 s

1 1 s- 1

I li-a

Function A 1
Function B i Demand
Function C J

Pilot Instruction to Monitor Departure Ground Frequency
(End of Service)
Update Ground Control Departure Q Ust

si*

§
11

Iff

O
I

1
|

Request received while flight decelerating

Gate No. Input required only if changed
from nominal assignment

1
o |

i
i

if <
ll

if o<2

I»rl

6 ; -j. 3
Ec|

^ z

o 1 'O

•a ° •=

BO 1

FUght ID. Ramp Destination, Status, Time of
Demand

Flight ID, Status-Docked/Parked

E a

2. 1

9 .

15.1

= S£

3 J J

Receive Gate Verification Request Message (Demand)
Retrieve Nominal Gate Assignment from Storage
Transmit Verification Request Message to Airline Opns
Receive Verification/Modification Message from Airline Opns
Transmit Gate Assignment Message to G.C. Subsystem
Update Gate Schedule

Received Ramp Status Request Message (Demand)

Function J

Transmit Ramp Conflict Message to G.C. Subsystem

Function H (No Conflict)

Determine FUght Docked/Parked at Gate (End of Service)

Function G

Transmit Ramp Available Message to Ground Control

Subsystem
Transmit Clearance to Gate for Flight Holding in Ramp
Update Inbound Ramp Q

1 i 1 1

if if B if if if if

| S"S

ll 1

■a | & .s is

111

JcSl

3
< J
1 1

O
1

»i 1 a
o J §

for performance of the function, start of service to an individual flight, or end of
service to an individual flight.

In general, "Demand" events involve the receipt of a request for per-
formance of the function by an interacting function or from an external interface
(e.g. , NAS enroute system). The exceptions are the pilot's indication that the
flight is ready to taxi for Function B, Monitor Outbound Ramp Q, and the pilot's
request for pushback clearance for Function C, Pushback Clearance. In general,
the flight will have already received service from the RCS under Function A,
Flight Clearance Delivery. "Start of Service" events involve the initial radio con-
tact with the flight awaiting service by the RCS. "End of Service" events are, as
indicated, an end of service to the flight by the RCS and involve communications
with the flight (or possibly airline operations when the flight docks or parks at its
gate). Typically, "Start of Service" and "End of Service" events require a real-
time data entry by ACTC or airline operations personnel. The "Demand" events
for Functions B and C will also require real-time data entry by ATCT or airline
operations personnel.

The fourth column in Table 3-1 indicates the data required for the per-
formance of the function by the data processing equipments. These data require-
ments may be derived from ASTC system data bases or ATCT/airline operations
personnel.

The fifth column indicates specific real-time data entries that must be
accomplished by the ATCT or airline operations personnel to initiate the perform-
ance or within the performance sequence of the function.

The last column provides particular qualifying remarks pertaining to
the performance of the functions or events with the performance sequence.

3. 2. 2. 2 Organizational Interaction of Functions

The interaction of the Ramp Control System functions can be readily
viewed as the logical and sequential processing of information within the ASTC
system data base organization. This is illustrated in Figure 3-3.

Flight clearances for IFR departures are received from the ARTCC.
They are delivered to the pilots when they call for their clearances. As indicated,
in the event that a change in the flight clearance is requested, it will be coordinated
with the ARTCC . The data contained in the final clearance as well as the preplanned
gate schedules may then be combined and stored in a Departure Flights Data file
for ready reference when the flight is ready for departure.

Flight clearances for VFR flights will also be delivered when the pilot
calls for entry into the system. In this instance, the beacon codes to be employed
by the flights will be assigned from a list of available codes obtained through the
interface with ARTS. Flight clearance data and the assigned beacon codes may then
be combined in the Departure Flights Data file. Since the flights are ready to taxi
upon receipt of their clearance, they may be immediately entered into Ground Con-
trol Departure Q for service by the Ground Control System. The Ground Control
Departure Q represents the list of aircraft waiting for service by the Ground Con-
trol System, i.e., waiting for instructions to enter the taxiway network from the
ramp areas.

As general aviation flights with IFR clearances are also ready to taxi
when they receive their clearance, they are also immediately entered into the
Ground Control Departure Q.

After some time, air carrier flights are ready for pushback. Flights
from non-Positive Ramp Control areas will push back and contact Ramp Control when
ready to taxi. They may then be entered into the Ground Control Departure Q.
Flights in Positive Ramp Control areas will call for their pushback clearance.
They would be entered into the Outbound Ramp Q for service. The Outbound Ramp
Q represents the list of aircraft in Positive Ramp Control areas awaiting or re-
ceiving service by the RCS in controlling their transition from pushback to the
Ground Control Departure Q. Ramp conflict management processing would deter-
mine the status of other flights, if any, in the Ground Control Departure Q and Out-
bound Ramp Q for the particular ramp areas. If there is a conflict, the flights

would be advised to hold at their gate and the process repeated in the next process-
ing cycle. If there is no conflict with other outbound flights, the ramp conflict
management processing would then determine the existence of any flights for the
particular ramp areas in the Inbound Ramp Q established by the Ground Control
System. The Inbound Ramp Q represents the list of aircraft, both still in the taxi-
way network approaching the turnoffs to the gates and holding in ramp areas, re-
quiring service by the RCS in providing clearance to their gates. In the event of a
conflict the flights would be advised to hold at their gates and the process repeated
in the next cycle. If no conflicts are determined, then the flights are cleared for
pushback and their status in the Outbound Ramp Q updated.

A short time later the flights' pilots will call for taxi. Their status
will then be updated in the Outbound Ramp Q. The ramp conflict management
processing will then be accomplished as previously described. If there is no con-
flict, the flight may then be entered into the Ground Control Departure Q.

Simultaneously with the updating of the flights' status data in the Out-
bound Ramp Q, the Gate Schedules data will be updated. The updating will reflect
the availability of the gates for arrivals entering the system. This data may also
be updated by airlines flight operations personnel when adjustments to the normal
flight Gate Schedules are anticipated.

This data will be accessed in relation to flights entered into the Ground
Control Arrivals Q list by the Local Control System. When necessary, the gate
availability verification process will require interaction with airlines flight opera-
tions to determine a revised gate assignment and/or delay in the availability of the
assigned gate for the flight.

At a later time the flights approaching the appropriate point of exit from
the taxiway network for their assigned gates will be entered into the Inbound Ramp
Q by the Ground Control System. Flights assigned to gates in non-Postiive Ramp
Control areas will be cleared to their gates by Ground Control. For flights inbound
to Positive Ramp Control areas, the ramp conflict management processing will

determine whether the Ground Control Departure Q or Outbound Ramp Q contains
conflicting departures for the appropriate ramp areas. When there are no con-
flicts, the flights will be cleared to the gates by Ground Control System and their
status in the Inbound Ramp Q updated. When there are conflicts, Ground Control
will retain control of the flights or, when possible, may clear flights off the taxi-
way network into a portion of the ramp area out of the way of the Positive Ramp
Control area traffic until it is cleared to the gate by Ramp Control. In the latter
event, the status of the flights in the Inbound Ramp Q would be updated. When
ramp conflict management processing subsequently determines that a conflict situ-
ation no longer exists, such holding flights will be cleared to their gates and their
status in the Inbound Ramp Q updated.

When the flights have docked or parked at their gates, they will be de-
leted from the Inbound Ramp Q. Simultaneously, the Gate Schedules data will be
updated to reflect that the gate is now occupied.

3.2.3 Description of Information Transfer for Individual Functions

The logical processing requirements for the performance of each Ramp
Control System function has been developed in detail. Flow diagrams and brief
narrative descriptions of each function are given below.

3.2.3.1 Flight Clearance Delivery (Function A)

The functional flow for Flight Clearance Delivery is illustrated in
Figure 3-4.

For IFR flights the process begins with the receipt of flight clearances
and any applicable delay restrictions from the ARTCC. Currently the flight clear-
ances are received and strips printed out at the FDEP in the tower. However, the
Operations Analysis at O'Hare indicated that a significant degree of marking of the
strips is then required by ATCT personnel. This includes:

• Annotating the equipment type for heavy aircraft and the
first fix

±1

FLIGHT

DATA

PREPARATION

/coordinateV

VWITH ARTCCy *"

V" DELIVER "N
"^ yCLEARANCEy

I HANDOFF TO
J GROUND CONTROL J
"^ DEPARTURE QUEUE I
FUNCTION

DEPARTURES/ l Wait for Maintain

DATA N Pushbock or Outbound Ramp

FILE \ \Clearance QUEUE Functions

Figure 3-4. Flight Clearance Delivery - Functional Flow Diagran

• Correcting the cleared altitude to the clearance limit that
can be issued for the tower/TRACON

• Entering the origination gate

t Entering the runway to which the flight is cleared for departure

In addition, Flight Clearance Delivery must manually prepare a flight
strip for VFR departures.

It has been assumed that the use of flight strips will be retained to pro-
vide a means of manual backup in the event of system equipment failures. There-
fore, the proposed concept for this function provides for a revised method of flight
strip preparation which minimizes the need for the strip marking listed above.

The data contained in the flight clearances and delay restrictions pro-
vided by the ARTCC would be combined with the Gate Schedule data and the standard
criteria for runway assignment to generate a composite flight clearance. The flight
strip would then be printed with the appropriate altitude clearance limit (if applicable),
flight originating gate, and nominally assigned runway. It is further assumed that
improvements could be made to the flight strip printer to provide for special annota-
tion of the flight equipment type for heavies and the first fix.

For VFR flights the ATCT personnel would enter the necessary data
for the flight. This would include the flight call sign (ID), equipment type, beacon
equipment type, and desired altitude and direction of flight out of terminal area.
This data would be combined with a beacon code selected from a list of available
codes provided by ARTS to prepare a flight strip.

For IFR flights the tower personnel would enter an acceptance of the
clearance delivered. This effectively enters the flights into the system for further
service. For air carrier flights this would involve establishment of the flight in the
Departure Flights Data file until it is ready for further service by the ASTC system.
This file is intended to contain only that reference data necessary for further service
by the ASTC system. This data could possibly be displayed to ground controllers for
planning purposes. It is estimated that this data would include:

Call sign

Equipment type or class

Beacon code

Computer number, if applicable

Originating gate

Departure fix ( or direction of flight for VFRs)

Nominal runway assignment

Delay restrictions, if applicable

For VFRs and general aviation IFRs, upon delivery of the clearance the
pilot would be directed to "taxi up to the taxiway and activate your beacon when ready-
to-taxi". The ASTC system sensor (e.g. , GEOSCAN) would automatically detect the
beacon and transfer the aircraft to the Handoff to Ground Control Departure Q func-
tion for further processing.

3. 2. 3. 2 Maintain Outbound Ramp Q (Function B)

The functional flow for the Maintain Outbound Ramp Q is illustrated in
Figure 3-5. This function applies only to air carrier flights. These flights will
enter the function for service from the other two functions depending upon whether
they are originating from gates in Positive or non-Positive Ramp Control areas.

When the pilot indicates that the flight is ready for taxi, the ATCT per-
sonnel will enter this into the system. Flights in non-Positive Ramp Control areas
will be transferred to the Handoff to Ground Control Departure Q function. The
data for the flight will be transferred from the Departure Flights Data file.

For a flight in Positive Ramp Control areas, its status would be up-
dated in the Outbound Ramp Q. The ramp conflict management functions would
then be called for processing of the flight's request for taxi. If no conflicts are
determined, the flight would be transferred to the Handoff to Ground Control De-
parture Q function. If a conflict is determined, the flight would be instructed to
hold in position. The flight would be re-entered for the ramp conflict management
functions in the next cycle.

Flight in
Positive Ramp
Control Area

I 1

I PUSHBACK |
CLEARANCE I
I FUNCTION I

l__

HANDOFF TO

GROUND CONTROL

DEPARTURE QUEUE

FUNCTION

Figure 3-5. Maintain Outbound Ramp Queue - Functional Flow Diagram

3.2.3.3 Pushback Clearance (Function C)

The functional flow for Pushback Clearance is illustrated in Figure 3-6.
This function serves only flights originating in Positive Ramp Control areas.

When the pilot requests Pushback Clearance the request would be
entered into the system. There are two possible methods by which this process
may occur. The pilot could directly contact the appropriate ATCT personnel
(Ramp Control) requesting pushback and the entry made by the ATCT personnel
(Ramp Control). As it is currently normal procedure for pilots to request an
authorization to pushback from their own flight operations personnel, the request
entry could be made by these personnel. The latter approach would be desirable
from the point of view of minimizing ATCT (Ramp Control) personnel voice chan-
nel and data entry workload. However, it would require agreement by the airlines.

A third alternative is also possible but would require installation of
data link/data entry equipment aboard aircraft. This approach might be considered
for future system evolution.

The flight's status in the Outbound Ramp Q would be updated. The ramp
conflict management functions would then be called for processing of the flight's re-
quest. If a conflict is determined the pilot would be instructed to hold at the gate
and the flight scheduled for further ramp conflict management processing in the
next cycle. If no conflict is determined the flight would be cleared for pushback.
The ATCT (Ramp Control) personnel or airline flight operations would enter the
pushback into the system updating the Outbound Ramp Q and Gate Schedules.

3. 2. 3.4 Inter-Departure Conflict Management (Function D)

The functional flow for the Inter-Departure Conflict Management is il-
lustrated in Figure 3-7. This function applies only to outbound flights in Positive
Ramp Control areas.

Flights will enter this function from either the Pushback Clearance or
Maintain Outbound Ramp Q functions, depending upon their pre-taxi status.

From Ground
Control System

-X- Entry could be made by Tower or Airlines
Flight Operations Personnel

Figure 3-6. Pushback Clearance ■

Functional Flow Diagram

Figure 3-7. Interdeparture Conflict Management - Functional Flow Diagram

The logical flow of the process can be readily followed from Fig-
ure 3-7 once some of the basic concepts of the logic are understood. Therefore,
it will not be followed in detail here. Rather, these basic concepts are defined.

The inherent rationale of this conflict management logic is that flights
in a "higher" status of readiness to taxi are given priority over flights in "lower"
readiness status. Proposed statuses would include:

• In (handed off to) Ground Control Departure O

• Ready to Taxi (in pushback position)

• In Pushback (but not ready to taxi)

• Pushback Request

In addition, priority is dependent upon the relative locations (i. e. ,
originating gates) of subject flights (i. e. , flights requesting advancement to next
higher status) and competing flights in the same ramp control area. In this con-
text, a flight is termed to be ahead of another flight if its originating gate is
literally farther out in the ramp area toward the taxiway network than the other
flights. It is not ahead of another flight if their gates are effectively abreast of
each other in the ramp area, i. e. , the pushback of one flight would block the push-
back of the other.

Therefore, when a subject (requesting) flight is not ahead of a com-
peting flight in the same ramp area, it would be allowed to advance to the next
higher status where there would be no conflict with the readiness status priority
rationale. This would also be true if the subject field is ahead of a competing
flight of a lower readiness status than the one requested. However, a subject
flight would not be allowed to advance to the next readiness status if in doing so it
would impede (delay) the movement of a competing flight in a higher status. The
determination of whether its advancement would impede the competing flight is
then made in terms of the status of the competing flight and, in some instances,
the length of time competing flight has been in that status. This is further dis-
cussed below for each instance.

The first checks in the process are made to determine whether there
are any competing flights in the Ground Control Departure Q for the ramp since
they are in the highest priority. Where a subject flight is ahead of a competing
flight in this status, it will normally be held in its current status. There may be
one exception when the subject flight is ready to taxi and the competing flight has
not been in the Ground Control Departure Q for a period of time equal to greater
than T H , where T is a parameter of the system. The rationale for this concept
is that if T-j is established at a sufficiently low value, then it would be improbable
that ground control had acted to clear the flight to taxi and enter the Ground Control
system. Therefore, the subject flight could also be entered into the Ground Con-
trol Departure Q without significantly impeding the movement of the competing
flight. A value of T = 30 seconds may be reasonable.

Similar approaches are proposed for the following situations:

• Subject flight is in ready-to-taxi status and the competing
flight is also in ready-to-taxi status but has been in this
status for less than a time T .

• Subject flight is in pushback request status and the com-
peting flight is in pushback status but has been in this
status for less than a time T .

Estimates of possible value for T and T may be determined on the
basis of the observations of flight operations in the ramp areas during the O'Hare
Operations Analysis. The observations indicated pushback times (i. e. , from initia-
tion of pushback to uncoupling of the tug tow bar) ranging from 10 seconds to 170
seconds, with an average of 73 seconds. The observations also indicated engine
start times (i. e. , from uncoupling to initiation of taxi ranging from 10 seconds to
175 seconds with an average 64 seconds. If T and T were set at appropriate
fractions of the pushback time and engine start times, respectively, then only a
portion of the competing flights might be slightly delayed in their total service
time in the ramp area. If these fractions were set at one-half, then fifty percent
of flights determined to be competing flights might be delayed one-half of the
pushback or taxi delay times, i. e. , 36.5 seconds or 32 seconds, respectively.

The incorporation of the above parametric decision approaches is
based upon the following rationale. The most efficient utilization of the ramp area,
system processing capacity, and controller flight handling capability will be ac-
complished when the ramp area is serving more than one departure at a time.
Thus, it will be of advantage to allow as many flights as is practical to be active
in the ramp area in various stages of readiness. To accomplish this some tol-
erances can be applied in possibly introducing a small amount of delay to a limited
portion of all departures. The appropriate balance between system efficiency, de-
gree of delays, and the portion of flights can be achieved by judiciously selecting
the parameter values for T„, T , and T .

However, it has been recognized that there is a practical upper limit
to the number of departures that can be active in a ramp area in various stages of
readiness. If too many departure flights are active in the ramp area, this could
lead to an increased probability of the ramp being unavailable for use by arrivals
with destination gates in the ramp. This in turn could result in increased proba-
bility of delays to flights or added workload on the Ground Control System.

A possible illustration of this situation is shown in Figure 3-8, ex-
tracted from an aerial photograph of O'Hare Airport. The figure shows four
departures active in the F-G ramp area. The status of the B-747 at gate F-3A is
not known with any certainty but, since the jetway is not connected, it could be
preparing for pushback as well. The figure also indicates two arrivals taxiing
on the Inner Circular taxiway. If either of these flights have a destination gate
in this ramp there could be significant delay in the availability of the ramp for taxi
to its gate. If the affected flight was the leading flight, then the second flight
might also be significantly delayed if the lead flight held on the taxiway for the
ramp to become clear. Observations made during the previous O'Hare Operations
Analysis indicated that the average time for taxi out of the ramp area was 54
seconds. Thus, if it was assumed for simplicity that all the departures shown in
Figure 3-8 are ready to taxi and that the aircraft on the Inner are held, then it

Figure 3-8. Example of Possible Ramp Area Congestion Problen
3-31

could require a minimum of 216 seconds (slightly over 3-1/2 minutes) before an
arrival could enter the ramp area to taxi to an inner gate. If any of the departures
were only starting their engines (observed engine start time = 64 seconds) this
delay could be even longer.

To avoid this situation a final logical check on the total activity level
of the ramp is proposed for flights requesting pushback for which no other inter-
departure conflicts have been determined. If there are less than N departures
active in the ramp, where N is a system parameter, , then it could be feasible to
allow the pushback; if not, a conflict exists. An estimate of a practical value of
this parameter N is derived as follows. It is assumed that on the average out-
bound flights are equally likely to have an origination gate in the outer or inner
portion of the ramp area. Similarly, on the average, inbound flights are likely to
have a destination gate in the outer or inner portion of the ramp area. Thus, on
the average an inbound is likely to have a gate ahead of N/2 of the outbound flights.
As will be noted in the description of the Outbound-Inbound Conflict Manage-
ment function logic the inbound flight would be given priority. Therefore,
it would be delayed only by those N/2 aircraft ahead of its destination gate (about
N/2). If it is assumed these N/2 flights were just beginning engine start, then an
inbound flight would face an average maximum delay (D,,) in seconds of

D M = f ( VV

where t and t are the average engine start and taxi out times. Similarly, if it
is assumed that these N/2 flights were beginning to taxi out, then the inbound flight
would face an average minimum delay (D ) in seconds of

Substituting the values for t and t observed at O'Hare then,

N
D = — (64 + 54) = 59N seconds

of N.

Table 3-2 lists the values of these delay extremes for several values

Table 3-2. Potential Maximum and Minimum Inbound Delays
for N Outbounds in the Ramp Area

D M (SGC)

D (sec)
m

118

177

236

108

295

135

From this table it can be seen that for N greater than 4 even the mini-
mum potential delay (D ) becomes excessive, i.e. , over two minutes. Thus, it
would appear that a value of N = 4 represents a practical parameter for limiting
the number of active outbound flights in a single Positive Ramp Control area.

Before a flight may be cleared to advance to the next higher state of
readiness, it is also necessary to determine whether this action would result in a
conflict with flights inbound to the ramp. Thus, all subject flights satisfying the
Inter-Departure Conflict Management criteria are transferred to the Outbound-
Inbound Conflict Management function.

When an inter-departure conflict is determined, the conflict condition
would be displayed to the tower (Ramp Control) personnel and the processing for
the flight returned to the originating function.

3.2.3.5 Handoff to Ground Control Departure Q (Function E)

The functional flow for Handoff to Ground Control Departure Q is
illustrated in Figure 3-9. IFR air carrier flights will enter this function from
the Maintain Outbound Ramp Q function. VFR and IFR general aviation will enter
this function from the Flight Clearance Delivery function.

I MAINTAIN ,

I OUTBOUND I

I RAMP QUEUE I

I FUNCTION

FLIGHT |

I CLEARANCE ,
DELIVERY
FUNCTION

INSTRUCT
PILOT TO MONITOR
GROUND CONTROL
FREQUENCY

Ground Control

System
(End of Ramp

Control Service)

Figure 3-9.

Handoff to Ground Control Departure Queue ■
Functional Flow Diagram

For flights in positive ramp control areas it will be necessary for the
ATCT (Ramp Control) personnel to enter the handoff into the system for transfer
of the flights to the Ground Control Departure Q. As air carrier flights enter the
Q, the Gate Schedules data will be updated to indicate that the gates from which
they departed are available for arrival flights.

3.2.3.6 Verify Gate Assignment (Function F)

The functional flow for Verify Gate Assignment, the first function for
arrivals, is illustrated in Figure 3-10. This function and the following functions
are applicable only to air carrier arrival flights.

An applicable flight will be entered into the Ground Control Arrival Q
List by the Local Control System*. When this occurs, the Gate Schedule data will
be accessed to determine the flight's assigned gate and the availability of the gate
for the flight. The Gate Schedule data may have been updated for one or more flights
when gate changes are known in advance by airlines flight operations.

If the flight's gate is available, the gate assignment and its availability
will be transmitted to the Ground Control System for use in routing of the flight
and communication to the pilot. A gate may be considered to be available if it is
currently open (i.e., no flight on the gate) or if the flight at the gate is in an active
status (i.e. , in Pushback, Ready-to-Taxi, or Handoff to Ground Control Departure
Q status). Airline decisions will also determine gate availability.

If the flight's gate is not available, a gate assignment/ availability
request message will be transmitted to the appropriate airline's flight operations.
Flight operations will enter the revised gate assignment and/or delay in availa-
bility. This data will update the Gate Schedules Data and will be transmitted to
the Ground Control System for use in flight routing and communi cation to the
pilot.

* Refer to Section 3.4

From Local
Control
System

, GROUND
Update ^ J CONTROL

3 Gate ARRIVAL

VerificoNon V QUEUE LIST
Request

Gate is available if it is
open or if Flight at Gate is
in Push back, Ready to
Taxi or Handed off to
Ground Control Departure
Queue Status.

ENTER
| GATE CHANGES
/ DELAYS

Airlines

Update

*" Ground Control
* System

Figure 3-10. Verify Gate Assignment - Functional Flow Diagram

3. 2. 3. 7 Monitor Inbound Ramp Q (Function G)

The functional flow for Monitor Inbound Ramp Q is illustrated in Figure
3-11. Flights will enter this function at some time after the performance of the
Verify Gate Assignment function. This will be accomplished through the entry
of the flight into the Inbound Ramp Q by the Ground Control. It is at this time that
checks will be started for Ramp entrance conflicts (see GCS).

For flights scheduled for gates in non-Positive Ramp Control areas,
no processing will occur until the flight docks or parks at its gate.

For flights scheduled for gates in Positive Ramp Control areas, the
Ground Control System will also transmit a ramp status request. The Outbound-
Inbound Conflict Management function would be called to determine whether a con-
flict exists. If a conflict is determined and the flight is still in the taxiway net-
work, a ramp conflict message would be transmitted to the Ground Control System.
If the flight is not on taxiway (i.e., it is holding in a portion of the ramp surface
clear of the gate ramp traffic), then it will be re-entered for service by the Out-
bound-Inbound Conflict Management function in its next cycle.

If no conflict is determined, the flight would be transferred to the
Clear to Gate function, i.e., Handoff by Ground Control System.

A short time later the flight will have taxied through the ramp area
and docked or parted at its gate. When this occurs, it will be entered into the
system. This will delete the flight from the Inbound Ramp Q and will update the
Gate Schedules data to show the gate as occupied.

As in the case of the entry of a pushback request, the entry that the
flight docked/parked could be made by the ATCT (Ramp Control) or airlines
flight operations personnel. The latter approach would be more desirable from
the points of view of minimizing tower controller communications and data entry
workload and avoiding voice channel congestion in the ramp area. However, it
would again require agreement by the airlines.

-X- May be entered by tower or
airlines flight operations.

Figure 3-11. Monitor Inbound Ramp Queue - Functional Flow Diagram

3. 2. 3. 8 Clear to Gate (Function H)

The function flow for Clear to Gate is illustrated in Figure 3-12. This
function applies only to arrivals scheduled for gates in Positive Ramp Control
areas. The flight will enter this function from the Monitor Inbound Ramp Q func-
tion when no conflict has been determined for the ramp area.

If the flight is still in the taxi way network, a ramp available message
will be transmitted to the Ground Control System for use by Ground Control. If
the flight is holding in an area of the ramp surface, the ATCT (Ramp Control)
will clear the flight to its gate and enter this clearance into the system.

In either case the Inbound Ramp Q will be updated to show the flight
status as cleared to the gate. This in effect reserves the ramp area from its
entrance to the point of the destination gate for the exclusive use of the arrival
flight.

The flight will then be transferred back to the Monitor Inbound Ramp
Q to wait for the report of its arrival at the gate.

* Waiting for Flight to
Dock /Pork.

Figure 3-12. Clear to Gate - Functional Flow Diagram

3. 2. 3. 9 Outbound-Inbound Conflict Management (Function J)

The functional flow for Outbound -Inbound Conflict Management is il-
lustrated in Figure 3-13. This function applies to both outbound and inbound flights
served by gates in Positive Ramp Control areas. Outbounds will enter this func-
tion from the Inter-Departure Conflict Management function. Inbounds will enter
from the Monitor Inbound Ramp Q function.

As in the case of the Inter-Departure Conflict Management function, the
logical flow can be readily followed once the basic concepts for the process are
understood. Therefore, these concepts are described here rather than the detailed
functional flow sequence.

The concept of one gate ahead of another discussed previously in con-
nection with the Inter-Departure Conflict Management function applies here as well.
In this case, it applies to the destination gate of the inbound flights in relation to
the origination gate of outbound flights.

In addition, the basic approach of defining a conflict as a situation that
would impede the flow of a flight in a higher priority status applies here as well.
For arrival flights the priority statuses defined here, in highest order first,
include:

1. Cleared to Gate

2. Within T seconds of arrival at the appropriate turnoff from the
the taxi network - second attempt at ramp entry*

3. Holding in ramp area for clearance to taxi to gate

4. Entering last link in taxi network prior to approaching the turn-
off intersection (more than T^ seconds from intersection ) -
Second attempt at ramp entry

*T^ is a system parameter which is a highly reliable prediction of the flight's
arrival at the turnoff intersection. The estimation of the value of T^ is discussed
in the Ground Control System section.

PUSHBACK
CLEARANCE
I FUNCTION

MAINTAIN
OUTBOUND
RAMP QUEUE
FUNCTION

Figure 3-13. Outbound-Inbound Conflict Management - Functional Flow Diagram

5. Within T^ seconds of arrival at the appropriate turnoff intersection -
first attempt at ramp entry

6. Entering last link prior to approaching turnoff intersection - first
attempt at ramp entry

Departure flights are compared against the status of flights in the In-
bound Ramp Q. Arrival flights are compared against the existence of flights in the
Ground Control Departure Q and the status of flights in the Outbound Ramp Q.

Flights in the Inbound Ramp Q for a given ramp would be acted on by
this function in the order of their priority status.

Flights in the Ground Control Departure Q are given priority over flights
in the Inbound Ramp Q .

When the gate for an active departure in the Outbound Ramp Q (i.e.,
the flight is in pushback or ready-to-taxi status) is ahead of the gate for the arrival,
then a conflict exists. The arrival would be returned to the Monitor Inbound Ramp
Q function and transmission of ramp conflict message to the Ground Control System,
as applicable.

When the gate for a non-active departure is ahead of the arrival's gate
(i. e. , flight is in pushback request status), the arrival is given priority. The ar-
rival is transferred to the Clear to Gate function for transmission of the clearance.
A conflict message is displayed to Ramp Control and the flight is returned to the
Pushback Clearance Function to be re-entered into the next conflict processing
cycle. However, when the destination gate for the arrival is ahead of the gate for
a departure in this status, then no conflict exists and both flights may be cleared
to proceed (the arrival to taxi to the gate and the departure to pushback).

When the destination gate for the arrival is ahead of the gate for an
active departure, the arrival is normally given priority. The exception occurs
when the arrival is in the lowest priority status and the departure is in the ready-
to-taxi status. In this situation, priority would be given to the departure. The
rationale for this priority is based upon these considerations:

1. It is most desirable to keep the outbound traffic flowing in a
reasonably constant stream to the runways in order that the opti-
mum capacity of runways can be achieved.

2. Delay of competing departures may also result in delays to other
departures in the ramp.

3. During busy periods there may be another arrival with the compet-
ing departure's gate as its destination and the gate should be
cleared as rapidly as possible.

In all situations, Ramp Control would be given a positive display of the
conflict or no conflict exists for each ramp and flights within the ramp.

3. 2. 3. 10 Controller Intervention/Override of Capabilities

The descriptions of the performance of the various RCS functions
provided in the preceding paragraphs represent the basic logical flows for these
functions. As in any other semi-automated real-time control system, especially
an air traffic control system, the capabilities for intervention in or override of
system logical decisions must be inherent in the system design. In the case of
the Ramp Control System concepts the ATCT (Ramp Control) personnel must have
the functional capabilities to review the results or cues of system processing in
relation to the overall situation to determine when such intervention is advanta-
geous. This intervention could take the form of decisions:

1. To deny a clearance to pushback or, conversely, to authorize
pushback in contradiction to control cues presented by the system.

2. To accomplish a handoff of an outbound flight to ground control in
contradiction to control cues (or, conversely, to delay a handoff).

3. To deny a clearance (or, conversely, to issue a clearance) for an
inbound flight to taxi to its gate.

4. To emphasize service to outbound or inbound flights in general
based upon the traffic situation.

Accomplishment of these capabilities must be afforded in the nature of
the information (control cues and other situation data) displayed to the Ramp Con-
trol position by the RCS as well as the data entry/retrieval features of the system.

As an example, consider a situation where a flight indicates it is
ready to taxi and the flight on a gate ahead of it is in pushback but not yet ready to
taxi. In this situation, the logic of Inter-Departure Conflict Management function
would determine that a conflict exists and this information would be displayed to
Ramp Control. However, depending on the types of aircraft involved and the exist-
ence or absence of aircraft on gates opposite to that of the pushback, it might
actually be possible for the requesting flight to safely taxi around the pushback.
In the observation of operations and analysis of the communications of ground con-
trol personnel at O'Hare it was noted that these personnel may ask a pilot if
he has room to pass a blocking flight. If the pilot responded affirmatively he would
receive the appropriate taxi instructions. This was observed for both the outbound
and inbound Ground Control positions. Therefore, if the RCS provided sufficient
information, Ramp Control could be capable of determining whether such a situ-
ation exists or to coordinate with the requesting flight on the situation in order to
decide whether to accept or override the displayed control cue.

The nature of potential information display features that could provide
the required capabilities for controller intervention/override will be discussed in
paragraph 3. 3.4.

3. 2. 4 Operational Requirements

Implementation of an RCS will be influenced by the operational environ-
ment of potential airports. This includes the physical configuration of the airport
facilities, traffic volume, and environmental conditions under which operations are
conducted.

3. 2. 4. 1 Physical Configuration of Airport Facilities

In general, Positive Ramp Control would primarily apply to the passen-
ger terminal ramp area. The most predominant physical characteristic of a termi-
nal configuration that would tend to necessitate Positive Ramp Control is one involv-
ing wings or fingers along which gates are located. Where these wings or fingers
are basically parallel and are sufficiently close to prohibit movement of more than
one flight at a time past aircraft parked at gates on both wings, then Positive Ramp
Control is likely to be required. In addition, when the wings are long, i. e. , more
aircraft gates in a given ramp area, Positive Ramp Control becomes more desir-
able to avoid conflicts between flight operations. The amount of separation between
parallel wings at which Positive Ramp Control would not be required is also depend-
ent on the types of aircraft operating at an airport. Airports having a significant
volume of wide-bodied aircraft traffic would require wider separation between par-
allel wings than those where the traffic is primarily non-heavy aircraft.

Other terminal area configurations in which Positive Ramp Control
may be required include cases wherein:

• A physical structure (such as a building or fence) is parallel or
opposite to the terminal gates.

• An aircraft parking area, for non-air-carrier aircraft, e. g. ,
general aviation or military aircraft, opposite to the terminal

A terminal building configuration other than parallel wings where
the ramp area entrance/exit throat does not permit simultaneous
passage of two aircraft.

• A multiple terminal building configuration (e. g. , J. F. Kennedy and
Los Angeles International Airports) where the distance between the
terminals does not permit simultaneous movements of two aircraft.

A ramp area configuration involving a Y configuration of the termi-
nal wings represents a special situation. Depending on the length of the wings and
the angle between them, there may be sufficient space for independent aircraft
movement at the outer portion of the ramp area. However, it is almost a cer-
tainty that Positive Ramp Control would be required in some portion of the inner
ramp area up to a point where the distance between the wings permits multiple air-
craft movements.

At some airports Positive Ramp Control might even be required in
cargo or hangar areas. Delays in the operation of aircraft in these areas may
not be as critical as delays for aircraft in the passenger terminal. However, de-
pending on the interface of these areas with the taxiway network, delays in the
movement of aircraft into or out of the areas could cause delays in the taxiway
network. Such situations could exist when access/egress from these areas to a
portion of taxiway network is by single taxi ramp and where the cargo/hangar
traffic mixes with the other airport traffic in that portion of the taxiway network.
Examples of such situations at O'Hare include:

1. The intersection of taxiway referred to as Hangar Alley with the
Scenic Taxiway, which carries departure traffic to runway 14L,
northwest of the ATCT.

2. The intersection of the same hangar area taxiway with the runway
14R/32L parallel taxiway, which carries departure traffic to 14R
or arrival traffic from 32L, southwest of the ATCT.

3. The intersection of cargo area ramp with the cargo taxiway, which
carries departure traffic for 22L or 27L or arrival traffic from 9R,
southeast of the ATCT.

During the O'Hare Operations Analysis it was observed that traffic
movement to or from the cargo or hangar required coordination between Inbound
Ground and Outbound Ground to control traffic flow at these intersections.

Similar situations may exist at other airports, necessitating Positive
Ramp Control for the ramp areas to avoid traffic flow problems in the taxiway
network.

3. 2. 4. 2 Ramp Area Traffic Volume

The airport ramp area configurations discussed above give rise to
potential ramp area traffic conflicts. However, the requirement for implementa-
tion of Positive Ramp Control in such areas is also dependent on the volume of
traffic served by the area. Obviously the higher the traffic operations rate the
greater the potential for traffic flow conflicts. An assessment is made of the
traffic conditions for which Positive Ramp Control is required as well as the
capacity requirements for the Ramp Control System.

Table 3-3 provides a summary of ramp congestion associated delays
observed at O'Hare. The table indicates the number of arrivals and departures to
various ramp areas during twelve observation periods, the computed hourly oper-
ations rate for the ramp areas, the ratio of arrivals to departures for the observa-
tion period, and the percent of aircraft operations experiencing delays.

The percentage of arrivals delayed included aircraft which were held
momentarily within the ramp area as well as those which were held on the taxiways
for access to the ramp areas. The former group represents holds noted during the
observation periods. The latter represents an estimate of the number of aircraft
held based upon the results of taxi hold analysis performed utilizing the ASDE
films taken by TSC and CSC. This analysis indicated that approximately 20 percent
of the arrival aircraft holds were due to ramp congestion; i. e. , the arrival was
held on the inner or outer taxiway or at an intersection of the outer and crossing
taxiways.

The percentage of departure flight delays represents momentary holds
of aircraft in the ramp area after they had begun to taxi from their pushback posi-
tion. It does not include delays in flight pushback by airlines (United or American)

rfl

■S ), §

£ &>

<-<

tr-

■*

"-"

— . "Tj

fc-

C\l

«D

< Q

1-1

es!

r " 1

1-1

e£

3 T5

0) 0)

1-1

Q Q

"ea 'O

5 &

C£>

co'

•<*

Csl

fi£

Sl.2

<s s

Tt<

0) S

«o

5-^

«M *H

o s

• £

C\l

Z ft

o «

o £

5 .2

$ | O

< ,0 W

1-1

r "'

ramp control personnel due to competing traffic or delays in issuing of taxi in-
structions because Outbound Ground was aware that the flight could not taxi due
to competing traffic. These delays could not be determined due to limitations of
data collection and/or analysis.

The limited amount of data available in Table 3-3 does not permit ana-
lytic determination of any parametric relationships. However, a number of sig-
nificant observations can be made from examination of this data:

1. The percent of operations delayed tends to be greater as the Ar-
rivals/Departure ratio is less than or approaches 1. 0. The ramp
area service times observed in the O'Hare Operations Analysis

(i. e. , average times of 200 seconds for departures and 75 seconds
for arrivals) would tend to support this observation.

2. The major exception to this observation occurs for the first entry
in the table. However, the traffic level for these observation peri-
ods is significantly lower than for other periods.

3. For periods when the Arrivals/Departure ratio exceeds 1. the
percentage of all flights delayed increases with the traffic opera-
tions rate.

4. The percentage of traffic delayed exceeds ten percent for all but
the one period with the low traffic operations rate.

Based upon this data two conclusions are drawn regarding the require-
ments for the Ramp Control System:

1. The system should be designed for a capacity of 20, and possibly
up to 25, operations per hour for each terminal building ramp area.

2. Positive Ramp Control should be implemented, when the traffic
volume is equal to or exceeds 14 operations per hour in a ramp
area with a configuration offering a potential for traffic flow con-
striction.

3. 2. 4. 3 Environmental Factors

Earlier in this section one of the criteria cited for classification of a
ramp area as requiring Positive Ramp Control was the lack of sufficient space for

simultaneous independent operations of two outbound aircraft or an outbound and an
inbound aircraft with a sufficient degree of safety during periods of poor operating
conditions. This is based on the assumption of reduced pilot capability for visual
reference to other aircraft, or physical structures. This factor suggests some
qualifications of the discussions in the preceding paragraphs.

Consider first the potential impact in areas where the terminal/ramp
configuration would not normally require Positive Ramp Control. This would be
because the terminal/ramp area configuration does not include any physical fea-
tures tending to constrain traffic movement (e. g. , terminal fingers, narrow throat
for ramp area entrance/exit) or because the distance between constraining features
is sufficient to permit multiple flight operations. Under Category II and lower
operating conditions pilot visibility may be sufficiently reduced so that wing tip
clearance requirements would have to be increased to assure an adequate safety
margin. Thus a ramp area that was not a candidate for Positive Ramp Control under
good visibility conditions might require Positive Ramp Control under poor operat-
ing conditions. In addition, reduced pilot forward visibility under these conditions
may necessitate greater care at the ramp area interface with the taxiway network,
particularly where outbound and inbound aircraft paths might cross due to their
points of entrance to or exit from the taxiway network.

Consider next the potential impact on areas which would not normally
require Positive Ramp Control because of a low traffic operations rate. Reduced
pilot visibility under poor operating conditions would require greater care in con-
trolling the movements of aircraft into and out of the ramp area. As an example,
the O'Hare Operations Analysis included a period of Category II conditions during
which visibility dropped briefly to effectively Category Ilia conditions. Throughout
this period, visibility of the low level of aircraft operations in the terminal ramp
areas from the ATCT was non-existent. Therefore, neither Outbound nor Inbound
Ground had any visual references to the relationship between departure and arrival
traffic for the same ramp area on which to control flight movements for the area.

During the brief period in which visibility dropped to effectively Cate-
gory Ilia conditions a pilot in one ramp area was given his taxi clearance by Out-
bound Ground. Just prior to that another departure flight from the same ramp
area had been given his taxi clearance by Outbound Ground. The pilot of the later
departure informed Outbound Ground that he did not have sufficient visibility to
determine the location of the previous departure ahead of him and that he would
not taxi until Outbound Ground could advise him of the position of the previous de-
parture. Outbound Ground had to contact the previous departure to determine that
it was clear of the ramp area and convey that information to the concerned pilot,
who then indicated that he was starting to taxi.

From the above discussion it would appear that under poor visibility
conditions it could become necessary or desirable to implement Positive Ramp
Control in areas that would not normally be controlled under good visibility condi-
tions. Therefore, the design of the ASTC system should permit the flexibility and
capacity to accomplish Positive Ramp Control in nominally Non- Positive Ramp
Control areas when operating visibility is sufficiently reduced to make such control
necessary.

3.3 PRELIMINARY DESCRIPTION

This section describes the RCS elements, data requirements, data
transmission across system interfaces, and information display and data entry
requirements for the performance of the RCS functions.

3. 3. 1 Overall Characteristics

The overall configuration of the proposed Ramp Control System is
illustrated in Figure 3-14. The RCS components include:

ARTCC (NAS) Interface Equipment
TRACON (ARTS) Interface Equipment
Central Data Processing Equipment
Ramp Control Input /Output Equipment
Automatic Gate Status Equipment
Control Communications Equipment

The ARTCC (NAS) Interface Equipment would provide for automated
data exchange with NAS for receipt of IFR flight clearances and delay restrictions.
The TRACON (ARTS) interface provides for receipt of available beacon codes for
VFR departures. Other coordination communications between the Ramp Control,
NAS, and ARTS personnel would be via voice landline facilities.

The Central Data Processing Equipment would be used for:

• Reception and integration of data received from ARTS and NAS
into the system data base.

• Maintenance of the data base required for the performance of the
Ramp Control System functions.

• Management of the interface with airlines flight operations, in-
cluding reception and integration of data entered via the Auto-
matic Gate Status Equipment (AGSE) and transmission of data
requests to the AGSE.

• Processing of system data to accomplish the functions of the sys-
tem, including the determination of ramp area traffic flow con-
flicts.

• Management of the interface with the Ramp Control Input/Output
Equipment, including reception and integration of data entered
via that equipment and generation of control information/cue dis-
plays.

The Central Data Processing Equipment is shown in Figure 3-14 as an

element of the RCS. It is probable in the total ASTC system configuration that it

would be shared among the Ground Control and Local Control Systems as well.

The Ramp Control Input/Output Equipment would provide the functional
capabilities for the man-machine interface between Ramp Control personnel and
the system processing features. This would include:

e Preparation of flight strips (in an improved format as discussed

earlier) for use in delivering flight clearances to IFR flights and
for use by ATCT personnel in a backup manual mode of opera-
tions.

• Presentation of the appropriate operational situation data and con-
trol cues information for use by Ramp Control personnel in assess-
ing and controlling ramp area operations.

• Entry of flight description, status, and control data as necessary.

The AGSE would provide the capabilities for the man/machine interface
between the airlines' flight operations personnel and the system data processing to
accomplish the coordination between airlines' flight operations and the ATCT. This
would include:

• Presentation of status information on flights under control of the

ASTC system.*

Presentation of requests for information on the availability of

gates for arrival flights.

o Entry of data on anticipated changes in gate schedules (assign-

ments), to be used in response to requests for gate availability
from arrival flights.

*It is considered probable that airlines' acceptance of some of the proposed RCS
concepts will be dependent on the benefits they might receive through availability
of data on the status of their flights for their own utilization.

• Entry of flight status data necessary for initiation of service to
departures in Positive Ramp Control areas and termination of
service to arrivals. *

It should be noted that, although not specifically shown in Figure 3-14,
airlines communications facilities also constitute an element of the RCS. This is
based on the assumption that pushback clearances and reporting of aircraft docking/
parking will be accomplished through airlines flight operations.

3.3.2 Data Requirements

Table 3-4 summarizes the data requirements for the performance of
the control functions of the Ramp Control System. The required data items are
grouped by category:

• Data pertaining to a particular flight.

• Data pertaining to the status of terminal gates (ramp locations).

• Data pertaining to departure delay restrictions.

• Data specific to the operational environment of the airport.

The control functions to which the various data items apply are in-
dicated on the table. Data items which may be utilized for information display
purposes are also indicated.

Operations data would be maintained in the system data base in a num-
ber of working files. These include:

• Departure Flights Data File

• Outbound Ramp Q

• Ground Control Departure Q

• Inbound Ramp Q

• Gate Schedule File

*Based on the assumption that entry of pushback clearance requests and flight
docking/parking status is made by the airlines to minimize voice channel loading
and controller workload.

Table 3-4. Summary of Data Requirements for Ramp Control System Functions

RAMP CONTROL SYSTEM FUNCTIONS

Z
<

z
o

Q UJ

2 5

a I

uj Z

3 3

z £

B
>

CE S

°fc

3 O

E 5
a <

O III

I- Q

UJ <

z h

3 O

I 1
< <

5 cr

Z jj

z
o

<
U

O -I
P

o u

DATA ITEMS

FLIGHT DATA

CALL SIGN

7 1

/ 2

AIRCRAFT EQUIPMENT TYPE

/ 3

/ 4

/ 3

BEACON EQUIPMENT TYPE

ASSIGNED BEACON CODE

CLEARED ALTITUDE (IFR)

DESIRED (CLEARED) ALTITUDE OUT

OFTERMINAL AREA (VFR)

FIRST FIX (IFR)

/ 4

DESIRED DIRECTION OF FLIGHT OUT OF

Z 4

TERMINAL AREA (VFR)

CLEARED ROUTE (IFR)

ORIGINATION GATE (RAMP LOCATION)

Z 5

/ 3

/
/

DESTINATION GATE (RAMP LOCATION)

/ 5

CURRENT RAMP DEPARTURE (READI-

NESS) STATUS

/ 3

CURRENT RAMP ARRIVAL STATUS

TIME OF DEMAND (ENTRY INTO

CURRENT STATUS)

/ 1

•/

./ 2

TERMINAL GATE (RAMP LOCATION) DATA

/ 3

z 3

/ 3

GATE (RAMP) SCHEDULES

CURRENT GATE (RAMP LOCATION) STATUS

GATE (RAMP LOCATION) AVAILABILITY DELAY

DEPARTURE RESTRICTIONS DATA

RESTRICTED DIRECTION(S) OF FLIGHT

DELAY RESTRICTION FOR EACH DIRECTION

OF FLIGHT

AIRPORT OPERATIONS DATA

IFR ALTITUDE CLEARANCE LIMIT(S)

DEPARTURE RUNWAY ASSIGNMENT CRITERIA

Z 6

Z 4 ' 6

AVAILABLE (VFR) BEACON CODES

NOTES

1. Required for Subject (Requesting) Departure flight and Competing departure flights in same Pi

2. Required for Subject departure (Arrival) and Competing Arrival (Departures)for same Positive

3. May be utilized in generating display for Ramp Control to permit intervention/override in sysl

4. Required for inclusion in Ground Control Departure Q data for use by Ground Control System

5. Derived for this function from Stored Gate (Ramp) data.

6. Reflected in ii

nof ni

runway assignm

n flight related data storage and outputs

The anticipated data contents of these files are summarized in
Table 3-5.

3.3.3 Interface/Data Transfer Considerations

The Ramp Control System requires data transfer with the external
ATC system (ARTCC and TRACON) as well as with the Ground Control System and
Local Control System components of the total ASTC system.

The data transfer associated with the ARTCC interface would be uni-
directional from the ARTCC (NAS) to the Ramp Control System. This data trans-
fer would include specific flight and general operations contraints, i. e. , delay
restrictions. The data items included in each transfer are given below.

Specific Flight Data

Call Sign

Proposed Departure Time

Aircraft (and Beacon) Equipment Type

Assigned Beacon Code

Cleared Altitude

Departure (First) Fix

Standard Instrument Departure (SID) Identification

Cleared Route (all components)

General Operations Data

Restricted Direction of Flight I

(or Departure Fix) I For each restricted direction (or fix)

Applicable Delay Restriction

Cancellations

The data transfer associated with the TRACON interface would be uni-
directional from the TRACON (ARTS) to the Ramp Control System. This data
transfer would include a list of beacon codes available for assignment to VFR de-
partures.

Table 3-5. Summary of Proposed Data Contents of Primary Ramp
Control System Working Files

Data Items

Departure
Flights
Data File

Outbound
Ramp Q

Ground
Control
Depar-
ture Q

Inbound
RampQ

Gate

(Ramp)

Schedules

Data File

Flight Call Sign

Aircraft Equipment Type
(or Class)

1
/

Assigned Beacon Code

Computer Number

2
/

Origination Gate (Ramp Location)

Destination Gate (Ramp Location)

Departure (First) Fix or Direc-
tion of Flight (for VFRs)

Nominal Runway Assignment

Departure (Delay) Restrictions
(if any)

Current Departure (Readiness)
Status

Current Ramp Arrival Status

Time of Demand (Entered Status)

Scheduled Flight

Nominal (Scheduled) Departure
Time

3
/

Nominal (Scheduled) Arrival
Time

Current Gate Status

Notes

1. Could be included for use (display) in controller intervention/override
capability.

2. If utilized in system (as in NAS and ARTS).

3. For each flight scheduled for use of Gate (Ramp Location).

The data transfer associated with the LCS interface would be unidirec-
tional from the Local Control System. This data transfer would include the call
sign of flights entering the Ground Control Arrivals Q as well as requests for
verification of Gate Assignment in the Ramp Control System.

The data transfer associated with the GCS interface would be bidirec-
tional between the Ramp Control and Ground Control Systems. These data trans-
fers will occur as entries to the Ground Control Departure Q, Verify Gate Assign-
ment, and Monitor Inbound Ramp Q functions. The data items included in each
transfer are given below.

1. Handoff to Ground Control Departure Q (From Ramp Control to
Ground Control)

Flight Call Sign

Aircraft Equipment Type (or Class)

Assigned Beacon Code

Computer Number

Origination Gate

Departure (First) Fix or Direction of Flight (for VFR)

Nominal Runway Assignment

Departure (Delay) Restrictions (if applicable)

Time of Demand

2. Verify Gate Assignment (From Ramp Control to Ground Control)

Flight Call Sign

Destination Gate (Ramp Location)

Gate (Ramp Location) Availability Delay (Zero or applicable
delay in minutes)

3. Monitor Inbound Ramp Q (From Ground Control to Ramp Control)

Flight Call Sign

Destination Gate (Ramp Location)

Ramp Arrival Status

Time of Demand (Entered Status)

Request for Ramp Area Availability

4. Monitor Inbound Ramp Q (From Ramp Control to Ground Control)

Flight Call Sign

Destination Gate (Ramp Location)

Ramp Area Available or Unavailable (conflict)

3.3.4 Display Considerations

The data which would be displayed to Ramp Control personnel in the
ATCT in connection with the performance of the various Ramp Control System
functions are described below.

The data for Clearance Delivery would be displayed in the form of a
flight strip prepared by the FDEP flight strip printer. The data that would be in-
cluded in either IFR or VFR flight strips are listed below.

IFR Flight Strip

Call Sign

Aircraft (and Beacon) Equipment Type

Assigned Beacon Code

Proposed Departure Time

Cleared Altitude or Altitude Clearance Limit (if appropriate)

Departure (First) Fix

Standard Instrument Departure Identification

Cleared Route (all components)

Origination Gate (Ramp Location)

Nominal Runway Assignment

Departure (Delay) Restriction (if applicable)

VFR Flight Strip

Call Sign

Aircraft (and Beacon) Equipment Type

Assigned Beacon Code

Cleared Altitude (out of terminal area)

Cleared Direction of Flight (out of terminal area)

Nominal Departure Runway Assignment

Departure Delay Restriction (if applicable)

The data display necessary for control of flight operations associated
with the Maintain Outbound Ramp Q, Pushback Clearance, Handoff to Ground Con-
trol Departure Q, and Monitor Inbound Ramp Q functions of the RCS are similar in
most respects. The required data and supplemental data items which could be dis-
played are summarized in Table 3-6. Supplemental data includes that information
which would be displayed to Ramp Control for evaluation of the ramp activity situa-
tion and determination of the appropriateness of intervention in the operations to
override system recommended control cues.

It may be noted that in each case the supplemental data is related to:

• The type (or class) of equipment of the subject requesting flight.

• The identity, origination/destination gate (ramp location), and
status of the conflicting outbound/inbound flight(s)

• The status of "opposing gates".

"Opposing gates" are defined as those gates on the opposite side of the
ramp area from that of the origination/destination gate of conflicting outbound/in-
bound flight(s).

The intent of the supplemental data would be to allow the Ramp Control
personnel to determine whether the potential exists for the subject (requesting)
flight to maneuver around the conflicting flight. If such a potential exists Ramp
Control could contact the pilot of the subject (requesting) flight to determine his
assessment of the potential. If the pilot indicated that such a maneuver was pos-
sible, then Ramp Control would clear the pilot to proceed under his own respon-
sibility. This process (representing shared responsibility in flight operations con-
trol as noted in the O'Hara Operations Analysis) is maintained in the Ramp Control
System, as well as in the Ground Control System, in order to achieve operational
flexibility and to avoid unnecessary delays.

Summary of Data Display for Flight Operations Control
Functions of Ramp Control System

Data for Display

Maintain
Outbound
Ramp Q

Pushback
Clear-
ance

Handoff
to Ground
Control
Depar-
ture Q

Maintain
Inbound
Ramp Q

Flight Call Sign

Aircraft Equipment Type (or Class)

Origination Gate (Ramp Location)

Destination Gate (Ramp Location)

Current Departure (Readiness) Status

Current Ramp Arrival Status

Time of Demand (Entered Status)

R,A

Outbound Conflict (Hold in Position)

No Outbound Conflict

Inbound Conflict (Hold in Position for
Flight Holding in Ramp Area)
or

No Inbound Conflict - Clear to Gate

Conflicting Flight(s) Call Sign

Opposing Gates Status

R = Required Data Item

S = Supplemental Data Item

A = Available, if needed

3.4 BENEFITS ASSESSMENT

The benefits assessment considers the impact of the RCS on aircraft
traffic delays as well as controller functional activities, i.e., communications
and flight strip marking. The assessment is made with respect to values obtained
during the O'Hare Operations Analysis. The impact is first determined for each
control function of the Ramp Control System. The total benefit is then deter-
mined as the sum of the benefits associated with each control function.

3.4.1 Flight Clearance Delivery Function

The potential areas of impact of the Flight Clearance Delivery
function are listed below.

Delays
None

Controller Communications

• Eliminate communications transactions (CTs) related to
obtaining departure gate from pilots.

Manual Activity

• Eliminate marking of clearance limit by Flight Data position.

• Eliminate marking of departure gate by Clearance Delivery

(Ramp Control in system concept).

• Eliminate need to obtain available beacon codes via ARTS
keyboard entry by Flight Data.

• Eliminate marking of departure runway assignment by Ground
Control .

• Manual preparation of a flight strip for a VFR departure by
Clearance Delivery will be replaced by entry of flight data
into the system for use in the proposed improved flight strip
preparation.

Based upon the measurements of controller activity at O'Hare, the
above CTs accounted for approximately 15 percent of the communications of the
Clearance Delivery position. Therefore, communications channel occupancy
for the Clearance Delivery (Ramp Control) position could be reduced by this
amount.

Based upon the controller manual activity analysis the above ac-
tivities represent approximately

• 27 percent of the manual activity of Flight Data

• 5 percent of the manual activity of Clearance Delivery

• 16 percent of the manual activity of Outbound Ground

Therefore, the manual activities workload of these positions could be reduced
by these amounts.

3.4.2 Maintain Outbound Ramp Q

The potential areas of impact of the Maintain Outbound Ramp Q
function are listed below.

Delays
None

Controller Communications
None

Manual Activity

• Addition of need to enter flight status (ready to taxi) for
air carrier departures into system would be balanced by
elimination of controller recording of time of request
since this recording would be automatically accomplished
by the system.

• Elimination of need to record time of request for general
aviation flights since this would be automatically accom-
plished at the time the flights are entered into the system
under Flight Clearance Delivery Function.

Based on the controller activity analyses the marking of ready-to-
taxi time for general aviation departures represented approximately 3.5 percent
of the manual activity of the Clearance Delivery Position. Thus, the manual
activities for Clearance Delivery (Ramp Control) could be reduced by this amount.

3.4.3 Pushback Clearance

Delays
None

Controller Communications

Elimination of CTs related to pilot request for pushback clear-
ance as these would be entered by airlines.

Manual Activities

Elimination of recording of time of request for pushback clear-
ance as this would be automatically recorded at the time of air-
line request entry.

Based on controller communications activities the above CTs
represented approximately 1 percent of the communications of the Clearance
Delivery position at O'Hare. Therefore, communications channel occupancy
for Clearance Delivery (Ramp Control) could be reduced by this amount.

Based upon the O'Hare Operations Analysis, flights requiring
pushback clearance represent less than 4 percent of the total operations. The
time spent in marking of request times for these flights, represents approx-
imately 1 percent of the manual activities of the Clearance Delivery and could
be eliminated by the proposed system concept.

3.4.4 Interdeparture Conflict Management

The areas of impact for this function by the nature of its definition
is limited to reducing delays for outbound flights (in relation to other outbound
flights).

The O'Hare Operations Analysis indicated that approximately 13 per-
cent of the air carrier departures experienced a delay in the ramp area, for an
average of 67 seconds. Most of these were caused by blockage by other depar-
tures. It is estimated that this situation accounted for 75 percent of the delays
(the remainder are due to ramp area arrivals).

For the purposes of this analysis the parameters employed in the pre-
vious O'Hare system effectiveness analysis are used here: 120 operations per busy
hour; 85 percent air carrier traffic; arrival/departure ratio of 1. 0. Based upon
these parameters and the above estimates the number of departure flight delays
which can occur may be computed as

(o. 85) (60) (0. 13) (0. 75) = 5 per busy hour.

This represents 335 seconds (5.6 minutes) of flight delay per busy hour.

3.4.5 Handoff to Ground Control Departure Q

Due to the nature of the definition of this function its potential im-
pact would be limited to the area of manual activity for the Ramp Control po-
sition.

In the description of the logic flow of this function in paragraph
3. 2. 3.5 it was indicated that flights would be entered into the Ground Control
Departure Q through a system data entry by Ramp Control when no conflicts
are determined for the flight. If it is estimated that this entry would take ap-
proximately two seconds, this would represent an increase of approximately
16.5 percent in the manual activities of the Clearance Delivery (Ramp Control)
position. Note, however, the system could be designed to automatically ac-
complish this transfer to the Ground Control Departure Q when no conflicts
are detected for a flight and to cue Ramp Control to accomplish the frequency
change (handover) instruction.

3.4.6 Verify Gate Assignment

Due to the nature of the definition of this function its impact would
be limited to the area of controller communications activity. This function
would eliminate the communications between flights and airlines flight opera-
tions because the flights' destination gates would be transmitted to the pilots
by (inbound) Ground Control as part of the flights' taxi clearance. However,
the communication of destination gate and availability information was observed
for approximately 60 percent of all arrivals in the analysis of controller com-
munications. Since, for the most part, these communications involved a re-
quest from Ground Control and a response from the pilot, a reduction in com-
munications activity would be achieved by a one-way transmission from the
Controller.

The net benefit is derived using the results of the (inbound) Ground
Control Communications analysis, namely

• Gate assignment communications for 60 percent of traffic.

• Gate assignment communications representing approximate-
ly 15 percent of all CTs.

• Average CT time of 9.3 seconds.

It is assumed that the one-way transmission of gate assignment
would involve one half of the time for the previous two-way communications.
Therefore, the net change in gate assignment communications time could be
computed as

["+ 0.40 (4.65) - 0.60 (4.65) 1 0.15 = -0.
0.60 (9.3)

025

That is, a net reduction of approximately 2.5 percent of the channel occu-
pancy of the (inbound) Ground Control would be accomplished.

3.4.7 Monitor Inbound Ramp Q

Within the proposed functional concept the reporting of arrival at
a gate would be accomplished through a system data entry by airlines flight
operations.

This reporting is occasionally performed, usually on request from
Inbound Ground Control, during low visibility conditions when flight operations
in the ramp area cannot be observed by Inbound Ground. However, such sit-
uations were not explicitly measured during the O'Hare Operations Analysis.
Therefore, no quantitative assessment of this impact can be derived here.

3.4.8 Clear to Gate

The areas of potential impact for this function are listed below.

Delays
None

Controller Communications

Addition of a Ramp Control communications transaction to clear
a flight that has been holding off the taxiway network in a portion
of the ramp area.

Manual Activity

Addition of controller (Ramp Control) flight status data entry —
Cleared to Gate — into the system when the flight is so cleared.

When a flight is instructed by Ground Control to hold in the ramp
area, Ground Control must also transmit the instruction to taxi to its gate at
a later time. Thus, the effect of this function would be to transfer this com-
munication from Ground Control to Ramp Control.

With respect to controller manual activity it is estimated that the
required data entry would take approximately 2 seconds for each occurrence.

Holding of arrival flights off the end of terminal building fingers
is accomplished occasionally at O'Hare but only for B-727 and smaller aircraft

because of the limitations of the space between the terminal fingers and the inner
taxiway. However, no explicit measurements of such situations were achieved
during the O'Hare Operations Analysis. Therefore, no quantitative estimates of
the impact of this function can be derived here.

3.4.9 Outbound- Inbound Conflict Management

The benefits of this function would be limited to reduction of de-
lays for both outbound aircraft and inbound aircraft. The specific effects an-
ticipated would be:

• Reduction of delays to outbound flights due to blockage
by inbound flights on the taxiways.

• Elimination of delays to inbound flights within the ramp
area due to blockage by outbound flights.

• Reduction of delays, to inbound flights outside the ramp
area, i.e., holding on the taxiway network, due to block-
age by outbound flights.

The effects of this function are assessed using the results of the
O'Hare Operations Analysis.

With respect to outbound flights, it was estimated in paragraph 3.3.3
that 13 percent of outbound flights were delayed in the ramp area and that 25 per-
cent of these delays were due to inbound flights. The average outbound delay was
noted in paragraph 3.4.4. to be 67 seconds.

With respect to inbound flights, delays within the ramp area were ob-
served to affect 8. 4 percent of the arrivals and to have an average duration of 90
seconds. The O'Hare analysis indicated that approximately 20 percent of arrivals
experienced delays on the taxiway network due to ramp congestion. The average
taxiway "hold" delay was measured as 67.5 seconds.

For the purposes of this analysis the parameters employed in the pre-
vious O'Hare system effectiveness analysis are used here: 120 operations per busy

hour; 85 percent air carrier traffic; arrival/departure ratio of 1. 0. Based upon
these parameters and the above estimates the number of flight delays which can
occur may be computed as:

(0. 85) (60) [(0. 13) (. 25) + (0. 084) + (0. 20)] =

51 [o. 033 + 0.084 = 0. 2ol = 16. 2 flights per busy hour

The delay time may be computed

51 [o. 033 (67) + 0. 084 (90) + 0. 20 (67. 5)] =
1187 seconds per busy hour

3.4.10 Composite Benefits

The results of the preceding analyses may be combined to provide
an estimate of the total (net) benefits of the proposed Ramp Control System.
These results indicate:

• A reduction of approximately 16 percent of the communication
channel occupancy (workload) of the Clearance Delivery
(Ramp Control) position.

• A reduction of approximately 2.5 percent of the communica-
tion channel occupancy (workload) of the Inbound Ground Con-
trol position.

• A reduction of approximately 27 percent of the manual ac-
tivities workload of the Flight Data position .

• An increase of approximately 7 percent of the manual ac-
tivities workload of the Clearance Delivery (Ramp Control)
position.

• A reduction of approximately 16 percent of the manual activi-
ties workload of the Outbound Ground Control position.

While there is a net increase in the manual activity workload of the
Clearance Delivery (Ramp Control) position, this does not seriously detract
from the overall benefits of the system concept. During the O'Hare Operations
Analysis the manual activity workload of this position was determined to

account for 16. 9 percent of the controller's time during a busy hour. In addition,
it was noted that these activities occurred, for the most part, simultaneously
with his communications activities. This situation is expected to continue in
the proposed Ramp Control System. Therefore, the reduction of approximate-
ly 16 percent of the controller's communications activity more than than com-
pensates for this increase in manual activity.

The estimated aircraft delays represent an extremely important factor.
The total estimated delay for all flights is 1522 seconds (25.4 minutes) per busy
hour. Using the weighted average cost of $11. 23 per aircraft operating minute de-
rived in the O'Hare system effectiveness analysis, this delay represents costs of:

• $285 per busy hour

• $4564 per day

• $1,665,860 per year

Estimates of actual savings due to the proposed RCS have not been made;
however, the above figures demonstrate the substantial costs incurred by the air-
line operators which could be reduced through application of positive Ramp Control
concepts.

SECTION 4 - DEVELOPMENT OF A GROUND CONTROL
SYSTEM (GCS) CONCEPT

4. 1 INTRODUCTION

Control of aircraft on the surface of an airport is a substantially differ-
ent control process from that performed at other ATC control positions. In gen-
eral the route structure of the airport is more complex than that in the airspace;
the number of aircraft sources (ramps, for example) are larger and the inter-
actions between surface traffic movement and the interacting local and ramp areas
more complex. Pilot options are more diverse since the aircraft can hold at al-
most any location and the navigational aspects, relying heavily on VGE equipment,
are appreciably different from those followed by the pilot when airborne.

The concentration of traffic in the vicinity of a major terminal is sig-
nificantly higher than that existing at other control positions. The relatively slow
speeds used by aircraft in taxiing, the unique aspects of aircraft turning (either
at intersections or at runway turnoffs), and the pavement constraints of most air-
ports, coupled with the recent advent of heavies, are some of the factors that
make the ground controller's job indeed a difficult one even in conditions of excel-
lent visibility. The experience of the pilots is believed to be a major factor in the
"workability" of the existing GCS. Aircraft taxiing on "highways" such as the
Outer Circular or some of the parallels at O'Hare maintain headway with respect
to each other. This type of conflict, therefore, is not something that a controller
must be concerned with since he knows that the pilots will exercise this function.
At intersections, however, no such "rules of the road" exist because of the single
lane nature of the existing pavements. Scheduling of the pavement facilities, which
must serve a wide variety of runway configurations, is by no means a simple task.
An idea of the complexity of the control functions may be obtained from the discus-
sion of the individual functions set forth under the performance requirement sec-
tion. The manner in which these interact with each other will be shown on a

composite operational logic figure. The required amount of functional activity in
the present manual system is compared in the benefits analysis section with those
anticipated in a semiautomated GCS.

4. 2 REQUIREMENTS ESTIMATION

4. 2. 1 General

The area of responsibility of the Ground Control System includes all
taxiway links and intersections exclusive, however, of ramp, cargo, and hangar
areas. This system must interface with other pavement areas (facilities) which
are under the control of other systems. These interface areas include the ramp
entry /exit areas, runway turnoff links, departure Q nodes serviced by Local Con-
trol, and the cargo and hangar areas from which aircraft may also wish to enter
the GCS. Runway crossings represent a facility managed on a time-shared basis
by both the Local Control system as well as the Ground Control System. During
some active runway configurations, inactive runways may be used (4L/22R at
O'Hare for example) for taxi purposes. These will be considered as part of the
taxi system for the particular runway configuration in use. The above description,
supplemented by the taxi network analysis of Appendix A, defines the required
coverage area of the Ground Control System. Special mention should be made of
staging areas (such as the Penalty Box at O'Hare) which are portions of the taxi-
way network wherein an aircraft is delayed because of the unavailability of a
facility (i. e. , a gate for example) outside of the ground controller's area of re-
sponsibility. Non-paved areas, service roads, fuel depots, and all areas closed
to aircraft traffic are excluded from the coverage area of the GCS.

4. 2. 2 Functional Requirements and Operational Logic

The major functions to be performed by the GCS have been derived
from a detailed study of existing control procedures and examination of aircraft
scenarios and maneuvers during their use of the various ground control facilities.
It is expected that some of these functions can be improved materially by use of

semi-automated control techniques; other functions, however, will still be per-
formed in a manner similar to the present-day system.

The control functions may be divided into three categories, based upon
whether they are required for Departures, Arrivals, or both.

These Control Functions are as follows:

Departures

A. Release of Departure A/C (from Ramp Areas) (including monitor-
ing status of Ground Control Departure Q)

B. Handoff to Local Control Departure Q.
Arrivals

C. Formation and Monitoring of Ground Control Arrival Q

D. Acceptance of Arrival A/C (into Taxi System)

E. Penalty Box/Staging Area Management

F. Interface/Handoff to Ramp Control
Common

G. Routing Control (Selection and Verification)

H. GCS Conflict Management

Each of these functions is examined in order to determine the informa-
tion needed by the data processing subsystem (or controller) to perform the appro-
priate job (or task). There is a substantial amount of interaction between many of
these Control Functions; for example, Function A requires (1) that Function H (no
Ramp Exit Conflict exists) is satisfied; (2) that Function G (Routing Control) has
been performed. In the present system the logic used is that if Function H is not
satisfied (i. e. , a Ramp Exit Conflict exists) then no contact is made by the
Ground Controller with the Departure A/C.

Table 4-1 lists the major Control Functions required in the Ground
Control System. This table also indicates where interface is required with the
associated Local Control or Ramp Control systems. The next heading of this
table lists (in order) the sequence of events or interacting functions which are to
be recognized or performed during the designated function. These entries may be
used to identify the demand (or request) for service; the actual initiation of service
and the completion of service for each function of the aircraft control process are
parts of a series of tandem queues managed by the controllers.

While some "Demand" events may be defined solely in terms of air-
craft location (and possibly other physical parameters), other "Demand" events
must be specified by the users (i. e. , a pilot indicating he is ready to taxi). On
the other hand, the events identifying Start and End of Service (or activity) are
essentially recognizable from surveillance information, i. e. , an aircraft has left
the Ramp Area, is about to turn off the runway after landing, or is "near" the
Local Control Departure Q. It is these events which must be examined for each
function in order to determine the performance requirements of the surveillance
sensor(s).

The next column on Table 4-1 provides an estimate of the information
(or data requirements) needed by the controller or data processing system. The
various types of data requirements (Link Occupancy, Movement Detection, etc. )
are discussed in the Appendices wherein estimates of the performance require-
ments of the sensors are given (and included in Table 4-1). Changes in these data
requirements are expected as refinements are made in the development of the
GCS concept.

The interaction between these Control Functions is described by an
Operational Logic diagram as shown in Figure 4-1. Aircraft wishing to enter the
taxi system are designated as being in the Ground Control Departure Q or the
Ground Control Arrival Q. Upon entry, these aircraft "move" into an "Active"
A/C status, i. e. , service is being provided by the taxiway facilities. Termination

Input from RCS

Acquisition + Track Initiation
(A/C "Active")

Ill

§ 1

i If

§ >• 1

III

If §
8| <„ 2
II II

1 1 f *

IS 1!

Change A/C to "Inactive-
Change A/C to "Active"

3 1

s 2

3 , 3

5 1

|~' .1

1 s

" 1

l* 1

£8.

■s

1" ' '

:| S

* m

■I ■

|".

1 b

Hi
°5

9 o

E 2
IS

a a

o E
11

a
1

1
1
1

i s

* J

s 1
55

it I

Iff !i

JE 1 <2 § 1

°JJ |S

III si

if f

Mill 1

1 L

S p

1 §

I 1

S k, o

II i
§"9 §■

11 i

HIS!

O o X § !§

E 1 1 si &

3~§

- 1

3 J

1 i
SI 1

if |

Jafi

* a S

|1|

3?l J

A/C in GCAQ (Function C)

Function HA (Turnoff Gen. Conflict Check)

Function G (Routing Control)

"OK-to- Accept" (FLAG)

Pilot Call-in (Data Entry by Controller)

Verification of Entry (FLAG)

Entry Recognition (into P.B.)-Temp End of Service
Pilot Callup or Input from RCS (FLAG)
Function G (Routing Control)
Function H-5 (Ramp Entrance Check)
Function H-3 (Taxiway/Taxiway Conflict Check)
Issue Clearance (Data Entry by Controller)
Function D (Acceptance of Arrival A/C)

lis!

lilt

ilil

3r£ i*£

II 1

S 1

1 a

gy |

■gC

11 I s

ill

! it*

i in

1
1
8

f
3

I
1

1
1

Merge type conflict usually
t = 15-30 sec (Pred. Time)
Of A/C using R/W
Initiate conflict evaluation

Active A/C only

If turn recognition is used

One A/C in "Hold" status
To distinguish "turns" from
conflicts
A/C changes to "Active" status

S Si

3 355 5

,!■!

, &§ , ft &
[la Ii it

10(25)

10(25)
10(25)

10(25)

si
Is

el
S.S

8.
lie

Pi
i|l

Link Occupancy (Active A/C); Route Data
Predicted Position of Taxiing A/C
From LCS (Estimated/Predicted Crossing Time)
Route; Link Occupancy; Movement Detection

Assigned Route; Link Occupancy
Movement Detection; Turn Recognition?

Per above plus
Turn Recognition

Per above

A/C Landing on R/W

Link Occupancy; Movement Detection

Movement Detection

Ramp Availability Data

i
f

s
1

1 1

ll
P

Function A

Status of R/W - Taxiway Crossing
Status of Taxiing A/C (FLAG)
Issue Clearance or Hold
Verify A/C Across R/W (FLAG)
Detection of "New" Conflicts (FLAG)

• Verify "Hold" CompUance (FLAG)
Monitoring of "Old" Conflicts (FLAG when over)

• Verify "Start-up" (FLAG No "Start-up")
Function D

Status of A/C Near R/W (FLAG)
Verify "Hold" CompUance (FLAG)
Function F

S § 1

o I

* o

o *

1 1

H-l Ramp Exit Conflicts

H-2 R/W Crossing Control
(may be performed for
either Arrivals-Deps.)

H-3 Taxiway/Taxiway Conflicts

H-4 Turnoff-Generated Conflicts
H-5 Ramp Entrance Conflict

1 I

(or suspension) of service to "Active" aircraft will occur when they are "handed
off" to the Local Control Departure Q, the Penalty Box, or the Ramp Control Sys-
tem. All "Active" aircraft are "continually" examined for conflict recognition
purposes. Where necessary (as determined by the Controller) certain aircraft
may be "Held" in order to resolve a potential conflict. These A/C (in the "Held"
A/C List) are reactivated by the Controller at some later time. In Figure 4-1
GCS activated "flags" to the Controller are indicated wherever controller inter-
vention is required, i.e.,

Clear departure A/C into taxiway system

Cleared departure A/C has not entered taxiway system

Provide route to cleared aircraft

A/C is "lost", i. e. , not following route

Conflict resolution, i. e. , "Hold" A/C, etc.

Clear "Held" A/C to move

R/W crossing clearance

Acceptance of arrival aircraft

Resolution of turn-off generalized conflicts

Ramp entrance conflicts

Penalty box routing

Time for Handoff

Five types of conflict have been identified for GCS Conflict Manage-
ment (Function H). These are:

H-l Ramp Exit Conflicts

H-2 R/W Crossing Conflicts

H-3 Taxiway/Taxiway Conflicts

H-4 Turn-off Generated Conflicts

H-5 Ramp Entrance Conflicts

With the exception of taxiway /taxiway conflicts, all others are deter-
ministic in nature, i. e. , they must only be evaluated at or near the time of

iillPH&i« j

demand. The turn-off- generated conflict is defined as that caused to aircraft in
the vicinity of landing aircraft turning off the runway (and having priority) .

4. 2. 3 Performance Requirements

4. 2. 3. 1 General

Each of the eight control functions to be performed by the GCS repre-
sents an activity involving the interaction of a data acquisition system, a data
processing system, and data inputs to and from the controller with the controller
directing aircraft movement by voice via a standard radio link.

Most of the Control Functions involve the provision of advisory notices
(Flags) to the controller and controller-to-machine indication of action taken.
However, a need for function verification has been identified, i. e. , an aircraft is
indeed following instructions as given by controller. This verification can be per-
formed as at present, i. e. , visual verification by controller or by machine proc-
ess, viz A/C does not move with "T" seconds, A/C moves after "Hold" instruc-
tion, etc.

The performance requirements of all eight control functions are dis-
cussed with technical analyses of certain aspects of requirements provided in the
Appendices. These aspects are estimates of required accuracies for the DAS
sensors, the minimum GCS response time for recognition of conflicts, etc.

The GCS response time represents the interval between the time an
event actually happens and the time it can be recognized by the controller. This
will vary with the particular type of indication used, i. e. , it is expected to be dif-
ferent for Movement Detection as contrasted with Link Occupancy. Transition of
an A/C from a "stopped" condition to a "moving" condition may be easily recog-
nized almost immediately under visual conditions. Using surveillance sensors,
algorithms must be established to define "movement"; the approach taken has been
that an aircraft moving at less than a specified threshold speed is considered as
"stopped". The GCS response time for this component would then be defined as

from the time the aircraft speed actually dropped below this threshold value to the
time this data element was available to the controller. In general, GCS response
times of from 2 seconds to 3 seconds have been specified since overall system re-
sponse time considerations indicate prediction intervals of from 15 seconds to 30
seconds are of most significance in the control process. Where non-critical func-
tions are involved, the GCS response time may be relaxed to 4 seconds to 7 sec-
onds. Tradeoffs can be made between GCS response time and sensor performance
requirements; these should be considered in the examination of specific sensor and
display approaches.

4. 2. 3. 2 Release of Departure Aircraft (Function A)

This function includes monitoring the status of the Ground Control De-
parture Q, i. e. , those aircraft "demanding" entry from the ramp area into the
taxi system, as well as the processes actually involved in release of A/C into the
taxi system.

Acquisition by the sensor system may be desirable for those aircraft
at the "head" of each sub-queue although this may pose special resolution problems.
An alternate method would rely on acquisition after the aircraft starts to move out
onto its first link.

Interface with the Ramp Control System is necessary to establish A/C
ID, ramp areas, and time of entry into the GC Departure Q. Monitoring of the
GC Departure Q is essentially a "housekeeping" function which can readily be per-
formed by a computer in a manner that should simplify the current handling and
monitoring of flight strips by the Outbound Ground Controller and Clearance De-
livery position.

Release of a Departure A/C from the Ground Control Departure Q into
the taxiway system is a function interacting with several other functions, namely
G and H. Function G (Routing Control) requires the controller to assign a depar-
ture R/W as well as a taxi route to the departing aircraft. The performance of

this function is not very time sensitive, i. e. , it could be performed before (one
minute to two minutes perhaps) the actual release of the aircraft. On the other
hand, performance of Function H (GCS Conflict Management) must be done in real
time with a minimum of delay. Accomplishment of this "merging" of aircraft with
nearby traffic will be examined under Function H; this type of conflict will be de-
fined as a "Ramp Exit Conflict". Successful completion of Functions G and H per-
mits the controller to release the aircraft into the system. It is now the "job" of
the sensor data processing equipments to recognize (i. e. , begin track) entry of
this particular aircraft into the taxi system. A logic flow diagram representing
activities to be performed during this function is shown in Figure 4-2.

Recognition of A/C entry onto the taxiway could be accomplished in a
variety of ways. These include:

• A "passage" detector at the ramp exit

• Movement detection on the designated R/l link

• Position detection on the R/l link (Link Occupancy)

• Combination of some of the above

As shown in the Appendices, the R/l links are short at O'Hare and air-
craft exit speeds are expected to range from 5 knots to 10 knots. The time avail-
able for acquisition and recognition of entry does not appear critical; a response
time of 4 seconds to 7 seconds for an individual Departure should be acceptable for
verification of entry. It should be noted, however, that in many cases aircraft are
released from a ramp area in "batches" and that this factor will play a role in the
update interval.

After permission to taxi has been given, the sensor system must verify
entrance of the aircraft into the taxi system. After initial acquisition of the target,
position information of sufficient accuracy should be available to recognize that the
aircraft has indeed moved out onto the designated R/l Link. If an aircraft standing
clear of the R/l link accelerates at 0. lg to 7. 5 knots (estimated ramp taxi speed)
and then maintains that velocity, it will cover 38.3 feet in five seconds. If a link

Part of Romp
Control System

|GI

SELECT A/C

AT TOP OF

LIST

Entries
From Romp Control
(FIFO)

1 | ROUTING |

R/w — — H CONTROL I
? ; FUNCTION G I

Delete from

G. C. Dept. Q List
NOTES'

1. FIFO Service to Various Ramp Areas

2. Multiple Departures from One Ramp Area may
Affect 6 C. Dept Q Order

3. Ramp Areas with Dual Nodes Expected to have
Slightly Different Logic

• Link Occupancy

• Movement Detection

Figure 4-2. Logic Flow Diagram for Release of Departures into
Taxiway System (Function A)

occupied test is defined as measured position (x g ) > 19. 2 feet and the position
error is normal with zero mean and standard deviation of 9. 6 feet, then an air-
craft at 38.3 feet (i.e. , five seconds into the link) will indicate link occupancy with
97.5 percent certainty and an aircraft clear of the link will indicate link occupancy
(i. e. , false alarm) only 2. 5 percent of the time. With a modest sample rate (e.g. ,
two seconds) worst case detection time is seven seconds satisfying the 4-7 second
specified. If position is sensed every 0. 1 seconds and measured position is com-
puted each 25 samples with a first order filter (see Appendix D) then the single
sensed position accuracy requirement can be relaxed to 25 feet (9. 6/. 38) and the
worst case detection time is 7. 5 seconds.

If Movement Detection of this aircraft (rather than Link Occupancy) is
used, similar position accuracy and detection time as above is required (see
Appendix D).

4. 2. 3. 3 Handoff to Local Control Departure Q (Function B)

Under present procedures the Outbound Ground Controller will "hand-
off" a Departure aircraft after it has passed the last node before the Local Control
Departure Q area. Since these links are relatively long for most Department Q
areas, the "handoff" time is not critical. It should of course take place sufficiently
before the Departure Q area so that Departures can be handled expeditiously by
Local Control if no Departure Q exists. This method of operation is based upon
the premise that no further taxiing conflicts can arise.

For the South runways at O'Hare these "last" links are as follows:

Approx.

Runway

Final Link

Link Length

S16/Y18

> 1000'

S14/Y12

> 1000'

14R

SI or S2/Y1

900/>1000'

22L or 27L

S11/Y17

> 1000'

32L

S15/Y12

900'

Similar lengths exist on the North side except for 9L where the "last"
link is about 500 ft long after the intersection of the New Scenic and the 9L/27R
parallel. Using a minimal estimated taxi speed of 12. 5 knots, an aircraft will
have moved onto the last link by 150 feet in seven seconds. With position detection
rationale as in paragraph 4. 2.3.2 a standard deviation on measured position of
37. 5 feet would provide 97. 5 percent probability of detection, 2. 5 percent proba-
bility of false alarm, and a worst case detection time of 7 + T . A 7-10 second

detection time requirement could be met with modest data rates (e.g. , T = 2
seconds).

4. 2. 3. 4 Formation and Monitoring of Ground Control Arrival Q (Function C)

The Inbound Ground Controller has responsibility at O'Hare for two
categories of aircraft. One category consists of aircraft at hangar areas wishing
to taxi to the ramp areas or those in the Penalty Box and are now ready to leave.
The other category is landing aircraft which are handed off to the Inbound Ground
Controller from either one of the two Local Control positions. It is this latter
category which must be handled rapidly. Operational factors involved in the "hand-
off" process from Local Control which must be considered include:

1. Selection of a particular R/W turnoff is the pilot's responsibility,
not the controller's.

2. In the present system it appears that the Local Controller will per-
form the handoff on an anticipatory basis, i. e. , while the plane is
still partially on the runway or near a turnoff which the Local Con-
troller believes will be used by the pilot. While this approach is
desirable for minimizing "handoff" delays, it could possibly result
in runway conflicts.

3 . Communications between pilot/ground controller must be confirmed
at handoff. A position report is usually given by the pilot at this time.

4. A "landing" aircraft takes from 30 seconds to 40 seconds from
runway threshold to turnoff. During most of this period this
particular aircraft must be considered as demanding "service" at
all R/W turnoff s (except of course those already passed). Meas-
urement of aircraft position and velocity data for prediction pur-
poses during R/W deceleration can permit reduction in the number
of potential "turnoffs" that could actually be used by the landing
aircraft.

5. Potential conflicts between aircraft entering turnoffs are most
likely to occur with the preceding landing aircraft which is taxi-
ing down the associated parallel taxiway (turnoff-generated con-
flicts).

6. Both "high speed" and "low speed" R/W turnoffs must be consid-
ered. The former intersects the runway with turnoff angles as
low as 30 degrees while the latter have intersecting angles near
90 degrees. This factor can be significant in detecting "Turn
Recognition" as a means of formation of the Ground Control Arrival
Q for landing aircraft. Aircraft velocity at turnoff is expected to
vary somewhat for these two cases.

7. The responsibility for runway status monitoring, or recognition
that the runway is clear or occupied, belongs to the Local Con-
troller.

8. For some runways (primarily on the North side of O'Hare) the
Local Control does not "handoff" the aircraft to Inbound Ground
Control at or near the R/W turnoff point. He will actually perform
taxi control until the landing aircraft has been brought across other
active runways.

To perform Function C it is recommended that "Arrival" aircraft from
hangars be handled as "popups" and entered into the Ground Control Arrival Q on a
manual basis since in many cases beacon codes must be assigned and temporary
(not flight numbers) aircraft IDs are employed. Aircraft reentering the taxi sys-
tem from the Penalty Box are simply reacquired as they leave the staging area.
Entry of landing aircraft, on the other hand, into the Ground Control Arrival Q
may be performed manually (as at present) or automatically. In the automatic
case a sensor system would recognize perhaps an aircraft turning at a particular
R/W turnoff (Turnoff Recognition) or occupancy of the turnoff link (Link Occupancy).

A logic flow chart for this function and the succeeding one (Function D -
Acceptance of Arrival A/C) is shown in Figure 4-3; this also depicts the interfac-
ing functions of Routing Control and GCS Conflict Management. The results of the
Operations Analysis effort at O'Hare showed that in almost no cases (8 out of over
700 arrivals) is an aircraft "held" at the turnoff link. It is believed that this policy

Possible Entry Methods

Turn Recognition —
Link Occupancy —
Turnoff Prediction —

GROUND CONTRO L ARRIVAL
► LANDING A/C

ty Box
RIVAL Q /

■[JH

Manual

Entry - Position

I.D./Beacon Code
Destination

To Functions
G and H

G CS

, „,,„,,,-, C0NFL | CT
Generated ] MANAG ement |
Conflicts i function h

Holds
To Active
Aircraft

Landing Aircraft Will Not Be
Held On "Turnoff" Links

ACCEPT
LANDING A/C

INTO
TAXI SYSTEM

ACCEPT OTHER
A/C INTO
TAXI SYSTEM

Issue
Clearance
To Taxi

RECOGNITION OF
A/C ENTRY
INTO SYSTEM

ADD A/C TO
ACTIVE LIST
DELETE FROM
G.C. ARRIVAL Q

Link Occup.
Movement Det.

Return to
JOB SCHEDULING

Figure 4-3.

Logic Flow Diagram for Entry of Arrival
Aircraft (Functions C and D)

is followed in order to expedite the aircraft off the runways. The Inbound Ground
Controller, therefore, if a conflict does exist with an aircraft taxiing; on the asso-
ciated parallel, must issue a "Hold" instruction to this aircraft in order to clear
the landing aircraft into the taxi system at turnoff as soon as possible. It is there-
fore highly desirable to recognize entry into the Ground Control Arrival Q (GCAQ)
as soon as possible. Turnoff Recognition or Turnoff Prediction, therefore, ap-
pears more desirable as a recognition of this event than does occupancy of the turn-
off link.

After the Inbound Ground Controller has issued taxi clearance (and
routing) to the landing aircraft, the sensor system should confirm (as was done
for ramp area departures) actual entry into the taxi system; i. e. , the aircraft
becomes an "Active" user of the taxi network.

If Turnoff Prediction is used as a method for early recognition of
"demand" for taxiway service by landing aircraft, the estimation techniques of
Appendix E may be used to obtain required position and velocity accuracy of sen-
sor data when the aircraft is braking on the runway. Using pre-turnoff speeds of
30 knots to 60 knots (50-100 fps) the error in Turnoff estimate due to Position error

while that due to the velocity error is

where t is the prediction time interval. If otj and at2 are taken as 2 seconds, then
a = 50 (2) = 100 ft for V = 30 knots and a V/V = 2/15 = 0. 13 or a = 0. 13 (50)
= 6.5 fps. These values represent performance requirements imposed on the
Local Control System because of its interaction with the Ground Control System
and are not shown on Table 4-1.

4. 2. 3. 5 Acceptance of Arrival Aircraft (Function D)

As described in the previous section landing aircraft must be imme-
diately accepted into the taxi system. The sensor system to verify entry may be
used to recognize aircraft heading change (Turn Recognition) near the turnoff point.
Alternately, position data may be used to determine link occupancy on the Runway/
Taxiway Turnoff Link. The former technique may offer certain advantages in a
position measurement system having unequal errors in the two coordinates although
higher sampling rates may be required. The Turnoff links are longer than the R/I
links and higher taxi speeds will be used. If Link Occupancy is used as the verifi-
cation criteria and the exit velocity is estimated at 30 knots then using position de-
tection rationale as in paragraph 4.2.3.2 a standard deviation on measured posi-
tion of 25 feet will provide 97. 5 percent probability of detection, 2. 5 percent proba-
bility of false alarm, and a detection time of 2-3 seconds with modest data rates
(e.g. , T = 2 seconds). It is estimated that the GCS response time for this function
should be two seconds to three seconds.

4. 2. 3. 6 Penalty Box/Staging Area Management (Function E)

Arrival aircraft which must be "held" in the Penalty Box or other stag-
ing areas because of gate unavailability or related reasons are handled somewhat
differently by the Inbound Ground Controller than aircraft which are "held" because
of conflicts. In the latter case the controller and/or the Ground Control system
will be able to determine the end of a conflict and therefore the need to change the
aircraft from a "Hold" condition to an "Active" or moving status. The time at
which an aircraft is ready to leave the Penalty Box or staging area must be fur-
nished to the controller either via communications with the pilot or possibly via
the Ramp Control system.

The Penalty Box at O'Hare is approximately 500 feet long and there-
fore can be used as a staging area for perhaps two to four aircraft depending on
equipment type. It has two entrance/exit nodes and is located fairly close to the
ramp areas.

The staging areas may be considered as the initial destination of those
landing aircraft which do not have a gate and the designated (by the controller) taxi
route is given on this basis. Recognition of aircraft entry into the Penalty Box by
the sensor/data processing system essentially completes the initial handling of this
aircraft; at this time the aircraft may be considered as moving into a non-active
status, i. e. , into the Penalty Box Q.

Demand by the pilot for release from the Penalty Box necessitates that
the Inbound Ground Controller (and Ground Control system) perform a release func-
tion similar to that of Function A, i. e. , both Conflict Management and Routing Con-
trol will be involved. If these are satisfied, permission to depart from the Penalty
Box can be given via the voice link. It may be desirable, because of the relatively
short distance between the Penalty Box and the ramp area, to interpose one addi-
tional step before permission to taxi is given. This step would be a check of the
status of the particular ramp area to determine that it is not blocked by several
departure aircraft.

Recognition of aircraft departure from the Penalty Box must next be
performed by the sensor/data processing system in order to verify that the con-
trol function has been complied with. Control of aircraft within the Penalty Box
area is not currently envisioned as a semi-automated function.

For those delayed aircraft which are placed in staging areas other
than the Penalty Box (such as the cargo taxiway for certain runway configurations)
recognition of the entry to and exit from this condition can be most readily per-
formed by movement detection (start/stop) in the designated "Hold" area. Appli-
cation of this method within the Penalty Box may impose more stringent resolution
requirements on the sensor system than at most other points in the taxi network.
Link (or node) occupancy at the two Penalty Box transitions possibly supplemented
by route history data or movement detection should be sufficient to support the
Penalty Box Management function.

The exit/entrance dimensions near the Penalty Box as well as antici-
pated aircraft speeds are expected to be similar to those of the Ramp Exit Function
A. Entrance verification response times of 7-10 seconds to temporarily end ser-
vice should be adequate. In seven seconds an aircraft moving at a typical ramp
speed of 7. 5 knots will travel 90 feet into the penalty box. With position detection
rationale as in paragraph 4. 2. 3. 2 a standard deviation of 25 feet would provide
97. 5 percent probability of detection, 2. 5 percent probability of false alarm and a
detection time of 7-10 seconds with modest data rates (e.g. , T = 2 seconds).
Exit verification response times and accuracy requirements are similar to those
of verifying entry into the taxi ways from the ramps (Function A).

Figure 4-4 illustrates the operational logic for this function.

4. 2. 3. 7 Interface/Handoff to Ramp Control (Function F)

Arrival aircraft entering the ramp area at O'Hare currently do not
"sign off" the Inbound Ground Control channel; it appears that the entrance event
is visually recognized by the controller and the aircraft is crossed out on the
scratch pad he uses to keep track of "Inbounds". Arrival aircraft, in many cases,
cannot enter most ramp areas if a "Departure" is in "pushback". This type of
scheduling conflict is one of the most prevalent at O'Hare and explains why so many
of the "Holds" occur in the vicinity of the Inner and Outer Circulars. While under
the present day system the Tower Controllers do not have responsibility for the
ramp area, it can readily be seen that they cannot perform their function of taxi-
way management unless they are cognizant of the status of the various ramp areas,
i. e. , their availability for a particular arrival.

A preliminary logic diagram for this function is shown in Figure 4-5
wherein "Arrival" aircraft within "X" feet (or a certain time - perhaps 20 seconds
to 30 seconds) of ramp entrance may be considered as requesting usage of the par-
ticular ramp. This information probably should be supplied to the Ramp Control
system for scheduling control of "pushbacks" and other "Arrivals". Initial check
of ramp area availability may be made by checking the status of the Ground Control

ACTIVE A/C

Delete from
"Active" List

ENTRY
RECOGNITION

PEN. BOX
STAGING AREA

A/C
STATUS
CHANGE

• Voice Comm.

• Link Occup.

• Movement Detection

Add to
Penalty Box ( GCAQP)

| A/C Waits inP.B. ( Track Suspended)

TAXI
REQUEST

Pi lot -Voice Comm.
Ramp Control System

ROUTING

*- HN CONTROL

I FUNCTION G

r — ■> L ~T" '

GCS

CONFLICT

MANAGEMENT

FUNCTION H

RELEASE A/C
FROM STAGING
CONTROLLER/PILOT
COMM.

ADD TO
"ACTIVE" LIST
DELETE FROM

GCAQP

RECOGNITION OF

A/C EXIT FROM

P. B. INTO TAXI

SYSTEM

RAMP
STATUS
CHECK

• Comm

• Link Occup.

• Movement Detection

Figure 4-4. Logic Flow Diagram Penalty Box/Staging Area Management
(Function E)

Link Occupancy

HELD A/C
LIST

ARRIVAL A/C WITHIN
x FT (OR SECONDS)
OF DESIGNATED RAMP
ENTRANCE

ISSUE

CLEARANCE

(HANDOFF)

FOR

RAMP ENTRANCE

MOVEMENT
DETECTION

VERIFY A/C
ENTERING RAMP

MOVE A/C
FROM "ACTIVE"
TO "HOLD" LIST

• Link Occupancy

• Beacon Shutdown

Figure 4-5. Logic Flow Diagram for Interface/Handoff to
Ramp Control (Function F)

Departure Q. However, this is not sufficient to establish ramp area availability
and it is envisioned that the Ramp Control system should have the capability of
providing status information to the Ground Control system that will permit an
availability decision to be performed.

If the ramp area is unavailable a "Hold" instruction must be issued and
the sensor system should recognize compliance with this instruction. If the ramp
area is available, a clearance/handoff may be issued or the lack of a "Hold" instruc-
tion can be interpreted by the pilot (as is done at present) that the ramp area is
available. Verification of the event that the arrival aircraft is proceeding into the
ramp area should be made prior to the last location at which the arrival aircraft
can be "held". This location might be on one of the Inner Links immediately pre-
ceding the R/l link to be used by the "Arrival", or possibly the I/O link directly
outside of the ramp entrance. The occurrence of this situation should be furnished
to the Ramp Control system for scheduling purposes.

While taxiway routing requirements for "Arrivals" are such that only
the ramp area must be specified, the handoff function can be most expeditiously
performed if specific gate information is available. For example, departure air-
craft close to the main terminal buildings and in "pushback" would not block "Arriv-
als" with gates farther out on the concourse fingers. It appears, therefore, that
the interface/handoff function may impose on the Ramp Control system the necessity
of some type of "block" or space availability estimation within the narrow, and often
crowded, ramp areas.

Sensor requirements for recognition of entrance demand, since predic-
tion of entrance time is desired, are not stringent in terms of position.

We have chosen a value between 50 feet and 100 feet which should have
only a small impact upon the estimated ramp arrival time. Measurement of the
existing velocity of the aircraft, except for movement detection purposes, cannot
be really used for prediction purposes due to time variations arising from "turns, "
"braking, " etc.

4.2.3.8 Routing Control Function G

The operational logic for the Routing Control function is shown in Fig-
ure 4-6. The three major components of this process are those of Route Selection,
Route Issuance, and Route Verification. Route Selection depends upon the particu-
lar runway configuration in use, the origin and destination of the taxiing aircraft,
and, in some cases, the aircraft equipment type. Standard routes are used in most
cases by the Inbound and Outbound Ground Controllers; these have been described in
the previous working paper on this contract. Issuance of the route (and confirma-
tion by the pilot that he understands it) takes place via voice communications.

While it is desirable that verification of the specified route be per-
formed by the Ground Controllers, this in many cases is extremely difficult because
of the aircraft load; therefore, extensive reliance is placed upon the fact that pilots
are quite familiar with the taxiway network at O'Hare. It should be noted that, as
part of our survey effort of visual guidance equipment at O'Hare, there are only a
limited number of signs that actually indicate to a pilot where he is; most signs
provide destination type rather than location information.

The designated route for a particular aircraft can serve a major role
in the conflict management function; specifically it would be used for conflict de-
tection purposes. Without this data, appreciably more data processing would be
required for the conflict detection "job".

In the semi-automated system it can be seen that a major problem in
inputing route data will exist if it is required that the controller enter this data at
the time it is issued to the pilot. An alternate approach, whereby the information
in the data base is presented to the controller for a particular operation and he then
selects one of perhaps two computer-displayed routes via a binary entry device,
appears to be a more desirable mode of operation which is compatible with the
needs of a semi-automated ground control system.

It is envisioned that the surveillance sensor data will be utilized for
monitoring the actual route followed by either the Arrival or Departure aircraft.

L~ +

-z.
o
o

2 ^ s

"is

cc. o

Upon recognition that an incorrect route is being followed by an aircraft, a flag
of some type will call this event to the attention of the controller. At this time he
will then take the appropriate action which may involve a keyboard entry device of
some type for route modification purposes. Moreover, since the specific turnoff of
an arrival from a runway cannot be firmly established until effected, this may im-
pact on the route to be followed by Arrival aircraft. Such a situation may require
an input either by the controller or from the data processing system of the actual
turnoff exercised by the incoming aircraft. The "Turnoff Recognition or Predic-
tion" function performed here as part of the Local Control System (at handoff), or
as part of the Ground Control System, can then serve as an input to the route selec-
tion process for arrivals.

In estimating the positional accuracy required by route verification,
the criteria used is to assure link detection (clear of the intersections at both ends)
for most of the links for which sole link occupancy is possible. These links are
represented largely by the O/O and S/O taxi ways (see Appendix A). The O/O are
largely over 600 feet long and the S/O range from 400-700 feet. If a length of
550 is chosen as representative then an accuracy of 20 feet (see Appendix C) is
adequate with modest sampling rates.

4. 2. 3. 9 GCS Conflict Management (Function H)

Conflicts may be defined as those situations wherein there is an appar-
ent demand for the same facility (i. e. , link or node) by two or more aircraft over-
lapping in time. Actual conflicts, of course, will almost never occur; while in
most cases they are resolved by the controller, the pilot of either aircraft can be
expected to take the necessary evasive action, i. e. , stop, slow down, request in-
structions, etc.

Conflicts for use of taxiway facilities may occur between two taxiing
aircraft or may arise between a taxiing aircraft and aircraft "in" the interfacing
Local Control and Ramp Control Systems. R/W Crossing Control, wherein the
crossing node is time shared by both the Local and Ground Controller, is an example

of the latter. Other examples may occur due to Ramp Area activity, i.e. , the re-
lease of aircraft from the Ground Control Departure Q (or Ramp Area) must con-
sider nearby taxiing aircraft. A similar situation exists for Function F (Interface/
Handoff to Ramp Control) wherein Ramp Area availability may necessitate a taxi-
way "Hold".

The Conflict Management function may be considered to comprise
several subfunctions as follows:

• Conflict Search and Recognition

• Presentation of Situation to Controller

• Resolution Verification

• Monitoring of Ongoing Conflicts

We have previously identified five types of conflicts which occur in the
Ground Control System. Of these only the Taxiway/Taxiway conflict is non-deter-
ministic in nature; all other conflicts can occur only because an aircraft is demand-
ing a specific type of service. A summary of these conflict types is given in Table
4-2. The semi-automated system concept is based upon the premise that Conflict
Resolution is performed in all cases by the controller. The accomplishment of the
other component of Conflict Management will depend upon the particular conflict
involved. These factors are discussed separately below for each of the five con-
flict types.

Table 4-2. Summary of Conflict Types (Ground Control System)

Conflict Type

Priority
Aircraft

Conflict Effect

Relative Occurrence

Ramp Exit

Taxiing A /C

Delay to Departure

Medium

Taxiway/Taxiway

Low

R/W Crossing

Landing A/C

Delay to Taxiing A/C

Medium (R/W Con-
figuration Dependent)

Turnoff-Generated

Landing A/C

Delay to Taxiing A/C

Low

Ramp Entrance

Ramp Departure

Delay to Arrival

High

4. 2.3. 9. 1 Ramp Exit Conflict (Function H-l)

Upon recognition of "demand", i. e. , an A/C in the Ground Control De-
parture Q, it is necessary to perform a Conflict Search of the "Active" Aircraft in
the immediate vicinity of the particular Ramp Area. If there are "Active" aircraft
(moving) in a manner that would conflict with the Departure aircraft, this situation
could be presented to the controller so that he would recognize the end of the con-
flict and release the Departure. Alternately, a "denial" signal could be presented
to the controller which would change to a "Go" signal upon end of the conflict. Pre-
diction of future position of the taxiing aircraft (causing the scheduling type conflict)
would be required.

4.2.3.9.2 R/W Crossing Conflict (Function H-2)

This conflict can only occur if two events are satisfied, i. e. , an air-
craft is "close" to crossing a R/W and an aircraft (under Local Control) is within
"X" seconds of the R/W Crossing. Conflict search and recognition based upon run-
way surveillance data need only be performed when necessary. This particular
type of conflict involving only two aircraft appears readily suitable for a GO/NO-
GO type display.

4. 2. 3. 9. 3 Taxiway/Taxiway Conflict (Function H-3)

While this type of conflict seldom occurs it does impose the greatest
surveillance load upon the controllers in the present system. Being non-determin-
istic it is necessary to continually perform a search for potential conflicts for all
"Active" aircraft. This search rate should be such that it does not unduly penalize
the system response time. If a one-second search rate is employed and there are,
say, 15 Active aircraft "in" the Ground Control System, then all possible pairs of
- J - = 105 would have to be examined every second in a system
without other control logic. This number, of course, can be substantially reduced
by using location algorithms, etc. , so that only pairs of aircraft within a certain
distance of each other or at a given location are evaluated. In fact, this criteria

should probably be employed in controlling the surveillance activities. Upon rec-
ognition of a conflict of this type, the situation may be displayed to the controller
in a manner perhaps showing the predicted position of each aircraft involved in the
projected conflict over the next 15 seconds to 25 seconds. Upon the controller tak-
ing action, i. e. , "holding" an aircraft, it is envisioned that the surveillance sys-
tem would recognize that one of the aircraft has stopped (Movement Detection).

Monitoring of on-going conflicts is essentially a subfunction directed
toward recognition of the end of a conflict (scheduling or otherwise) so that an in-
dication may be given to the controller that a "Hold" aircraft must be changed into
an "Active" status.

While further effort is required in this area to define the necessary
surveillance requirements, the results given in Appendix E indicate that values of
ax of 50 ft will result in prediction time errors of about 2 seconds. Measurement
of present velocity of the aircraft does not appear to be a significant parameter for
prediction of future A/C position because of acceleration/deceleration effects over
the prediction period of 15 seconds to 30 seconds. It is currently believed that, if
the aircraft is recognized as "moving", estimated taxi velocities can be assigned
to the aircraft depending upon its location. For example, in the Inner /Outer area
a nominal taxi speed of perhaps 12 knots would be used for conflict estimation pur-
poses. On links closer to the runways values of taxi speed of 20 knots to 25 knots
might be used.

Aircraft on the same highway, i. e. , maintaining headway between each
other, would not be considered to be in conflict since this is the pilot's responsibil-
ity. This should substantially reduce the number of apparent conflicts.

4. 2. 3. 9. 4 Turnoff-Generated Conflicts (Function H-4)

These are very similar to those of the R/W Crossing type with the ex-
ception that the actual turnoff cannot be positively estimated in advance. "Turnoff
Recognition", i. e. , change of heading of the landing aircraft, may be an event which

could trigger this conflict recognition process. Aircraft on the parallels in the vi-
cinity of the turnoffs would then be presented to the controller who would inform
them to "hold" if necessary. It is not expected that this conflict will occur often.
Alternately, the situation existing on the runway/parallel could be presented to the
Ground Controller when the landing aircraft's speed had dropped below, say, 60
knots. This would indicate whether any action was required. Acceptance of the
landing aircraft into the taxi system (Function D) and recognition thereof would in-
dicate the "end" of this type of conflict.

4.2.3.9.5 Ramp Entrance Conflict (Function H-5)

This conflict is caused by Departure A/C in the Ramp Area essentially
making it unavailable for an Arrival aircraft that is within perhaps 30 seconds to
45 seconds of entry. It is primarily a scheduling problem which occurs often and
has been discussed under Function F. It is not envisioned that this type of conflict
will impose stringent requirements upon the surveillance needs of the Ground Con-
trol System. However, it will impose additional requirements on the Ramp Control
System, i. e. , the need to distinguish between Arrivals and Departures and possibly
the desirability of recognizing approximate location (in the Ramp area) of Depar-
tures in the Pushback mode.

4.2.4 Operational Requirements

The principal operational requirements that have to be satisfied by the
semi-automated, real-time Ground Control System are:

1. Compatibility with the current Tower Ground Control procedures
and methodology.

2. Output indications to aid and augment Ground Controller perform-
ance and reduce Ground Controller workload.

3. Output indications to permit safe and efficient control of aircraft
under visibility conditions in which the pilot can see to taxi but
controller's visibility is limited.

4. Output indications are to be in the form of displays oriented to the
specific function to be performed, i. e. , selective vs all inclusive.

5. "Job" scheduling primarily arranged by the Ground Control Sys-
tem, not Controller. Controller to have override capability.

6. The Ground Control System must operate satisfactorily with the
maximum peak aircraft traffic load.

During normal (daytime) weekday hours under good weather conditions
the hourly aircraft load on the total GCS at O'Hare has been found to range from 8
to 12 (aircraft -hours per hour) although a peak value of 15. 4 was observed during
the survey efforts. These values occurred during airport operational rates of 120-
140/hour. These values do not include A/C awaiting entry into the taxi system (at
the R/Ws or Ramp areas) nor do they include A/C in the Local Control Departure
Q area. Previous studies have shown that the ratio of short term "peaks" over a
5-minute interval with respect to the hourly load may range from 1. 5 to 2. 0.
Translation of the above to an operational level of 200 operations/hour gives hourly
"load" values of — — x 13 (an estimate) or 20; in peak 5-minute periods, 30-40 air-
craft would be "in" the system either taxiing to or from the ramp, in the Penalty
Box, or in a "Hold" condition. As a check on the above conclusions the following
analysis may be compared with the above.

If it is assumed that A/C movement on the airport past fixed points or
segments can be modeled by a Poisson distribution, then at 99. 6 percent probabil-
ity no more than 4 A/C (or a queue of 3) will be attempting to pass at one instant of
time.

If also the airport is working fairly smoothly at maximum capacity
(probably no more than 200 operations /hour at O'Hare) the above conditions can be
expected to occur over all major elements of A/C movement, i. e. , expected A/C
densities are:

Ramp Departure Queues 3

Departures, Inner/Outer 4

Departures, Taxiways 8 ( 2 RW)

RW Departure Queues (Local Control De-
parture Q) 6 (2 RW)

RW Effective Occupancy 4 (4 RW)

Arrivals, Taxiways 8 (2 RW)

Arrivals, Inner/Outer 4

Arrivals, Staging Area 3

Total 40

For individual controller positions, these totals relate to:

Arrival Ground Control 15

Departure Ground Control 15
Local Control North 5

Local Control South 5

From the above it is estimated that the GCS should be capable of main-
taining "track" on about 50 aircraft (25 percent margin) at one time.

In addition we are interested in the rate at which tracks must be estab-
lished. Tracks must be initiated for:

A/C Entering from Ramp Area 90-100/hr.

Arrival A/C

Landing/Turnoffs 90-100/hr.

Hangar/Popups 10-20/hr.

Penalty Box Exits 10-20/hr .

Total 240/hr.

Special needs (other vehicles, reacquisition, etc. ) may be expected to
lis by 25 percent or 1
or 10 track initiations/minute.

4.3 MODULE DESCRIPTION

4. 3. 1 Overall Characteristics

The GCS Module involves a Data Acquisition System (DAS), a Data
Processing System (DPS) and inputs/outputs to and from the Controller via Dis-
plays and simple keyboards as shown in Figure 4-7.

The DAS can be a single scheme such as GEOSCAN or an integration of
separate elements. However, it should respond to "Job" scheduling demands of the
DPS and provide A/C data as required.

The DPS provides all the machine elements of the Control Functions
and data for displays to the Controllers and accepts Controller Action indications.
In addition, the DPS interfaces with the RCS and the LCS by maintenance of A/C
files as the A/C moves between control of the three modules.

Controller displays are to be based upon the discrete requirements of
the controller position, i. e. , Arrival vs Departure. Typically two displays are
envisioned, one an alpha-numeric display indicating A/C awaiting entry from the
LCS or RCS together with a simple A/C file of A/C in the system; and a schematic
display for conflict situation presentation. A highly simplified controller entry
device is required to indicate controller actions- A/C entry acceptance, "Hold"
instruction, handover, etc. , plus features for overriding the "Job" scheduling
feature of the DPS to obtain a display of any specific airport surface area.

While this description of the Ground Control System has been based
upon the use of a single data processor, integration of this system with the similar
LCS may be feasible permitting the use of a single processor for use of both systems.

4. 3. 2 Interface Considerations

The GCS must interface with the RCS and the LCS. Interfacing with
the LCS will involve the interchange of A/C data for computing safe conditions for
Runway Crossing Control, and Handoff A/C file data for A/C transferring under
control between the two systems.

Demand

Data

CONTROLLER
DISPLAY

CONTROLLER
ENTRY

Figure 4-7. GCS Module

Similarly an interface is required between the RCS and the GCS. In
this instance arrival A/C files require data from the RCS as to whether the destina-
tion is clear or whether routing to the Penalty Box is required. For this feature
the GCS processor must supply the RCS with expected time of the arrival A/C at
its destination.

For departure aircraft the RCS must enter RTT A/C files into the De-
parture Q of the GCS.

4. 4 BENEFIT ANALYSIS

4. 4. 1 General

The major benefits derived by the GCS are keyed to controller work-
load especially under poor visibility conditions. By reducing controller workload
through the implementation of a semi-automatic system the controller can:

1. Devote more time (judgment) to individual conflicts requiring his
attention.

2. Maintain alertness for potentially dangerous situations.

3. Work under high stress conditions with reduced mental fatigue.

The above factors probably will produce situations of reduced aircraft
delay under peak traffic load and certainly improve safety and efficiency.

Under poor visibility conditions controller workload will be further re-
duced as the controller will not have to continually call A/C for position reports as
is currently done. In addition, the feature of automatic A/C route verification pro-
duces a level of safety not available in the current system.

Under poor visibility conditions, the current controller workload in-
creases because:

• Departure queues become extensive, causing blocking of Inner and
Outer Links.

• Controllers increase use of "Holds" for safety purposes and reso-
lution of taxi conflicts due to long departure queues.

• Controllers may not have normal visual access to A/C and may
have to resort to Pilot Position Reports and/or ASDE interpretation.

• Normal traffic disruption interfering with Gate Scheduling causes
increased Penalty Box Staging of arrival aircraft.

In addition the visual displays currently under consideration for the
GCS will be functionally oriented (i. e. , selective) so that only that information needed
for the particular function is displayed. This selective process is envisioned as
providing capabilities for display of portions (ramp exit/entrance area; R/W cross-
ings area, turnoff area, etc. ) of the airport as the need arises. This selective
process coupled with the availability of A/C ID should permit substantial improve-
ment in the control process under poor visibility conditions. As will be shown
later in this section, the controller workload is expected to be reduced by about 30
percent in conditions of good visibility; the reduction in poor visibility should be
even greater.

The current extensive controller requirements of A/C position reports
by radio communication transactions will no longer be required with the semi-auto-
matic system, and "lost" aircraft situations will be automatically reported to the
controller.

The compatibility requirement intimates that operations with the GCS
will incorporate much of the same methodology, radio communication discipline
and protocol, and flight strip handling (for departure aircraft) as is in use at present.

Controller performance augmentation is to be achieved through a dis-
play system that automatically alerts the controller to:

Potential taxiing conflicts

R/W turnoff conflicts

Lost aircraft situations

R/W crossing requirements

Handover situations

Presence of aircraft in Ground Control Departure Q and status of
Ramp Exit Areas (Ramp Exit Conflict)

4. 4. 2 Workload Reduction

While controller/pilot communications represent a substantial part of
the controller's work load (and is readily measurable), the data collection (primar-
ily visual surveillance) and interpretation portion of the controller's activities are
of primary significance in establishing how well he can perform the various control
functions. The controller can do some scheduling, or selection, of which function
is to be done next, i. e. , he can defer a "Handoff" if a higher priority function needs
his attention. However, the scheduling of his activities is most strongly influenced
by the random nature of aircraft maneuvers and the use of the communication chan-
nel. This scheduling process is supported also by pilot actions; if the controller
cannot "handle" an aircraft at a particular time, the pilot may slow down or wait
for the controller's actions.

An attempt has been made to establish the total functional load on the
overall GCS under conditions of good visibility. This estimate is given in Table
4-3. In periods of poor visibility, this functional load will increase with the pres-
ent system due to lack of surveillance capabilities, decreased A/C speeds, etc.
The functional activity or load on the controller is then estimated in Table 4-3 for
a semi -automated system which not only provides surveillance inputs for the con-
troller but provides conflict detection capabilities for assisting the controller in
scheduling his activities.

The functional activity estimate in the present system has been based
upon the hourly operations rate shown in the table (180 operations/hour). The
second column, labeled "Conflict/Repeat Factor", represents the estimated in-
crease in the number of times the particular function has to be performed because
of conflicts, lack of data, or controller unavailability. This will not be readily
apparent from analysis of communications; for example, a controller when seeing
a ramp exit conflict simply goes on to another function without talking to the pilot,
then reevaluates the situation again, etc. Translation of the modified hourly activ-
ity rate to the load occurring in a "peak" minute has been based upon factors

5.H >i

< a c

— . 0) 0)

Sflft

33 -*

1 A

03
U

in in

• co

a
O

Oi 00
CM* i-"

O ■>* CO

co © co"

LO'

O i-?

o
8

CM*
CO

a»

e
o

«s

en oo

CO rH

CO*

O ^f w
co" O "tf

ST
©'

CD ^
CO CO

CM «*
CO* I>

--■;>

O
CM

•^ 5

O CM

m (M o

r-,

O in

-a

o
o

ft §

CM* r-i

r-i r-i CM*

CM r-1

1-1

0) >,

6 "S

00 O

O O O

®1

00 in

O OS

CM CM CO

O CO

£3

Uzl

cd
ft

£ a»

o
o

CM O

O O CO

cm in

O O

O O O

o o

OS Oi

!M CM O

Ci C5

ft*

1-1

rl i-i

1-1

_,_,

Q
O

£
o

< 1

« £

> a>

CQ M

2 o

Eg O

o .S

1 1

>j 0)

3^ 8

o
U

CD
O

O CO

U
O

3! S

"^ § CO

*8 « Q

» g«

5 >>£

a — o

CD 03 XJ
O fl fl
O CC

."S co
X O

£ a g

< J

K co
m

o 2

CD cm
3 O

a
o

£
o

o
1

o
U

hJD

3
O

.2
o

o
o

ft ft*

r-l CM
1 1

« — 3
H " H

i i

3
1

« n

< ft H

K ffi

ffi

< PQ

QW^

_ i <U T3 CD

determined in previous studies for the FAA where the ratio of "peaks" in a 5-
minute period to the hourly load was found to range from 1. 3 to about 1. 7. The
values of functional activity in the "peak" minute have been summed for "Depar-
tures" (Functions A and B), "Arrival" and Common Factors (Functions G and H).
The total peak load of 34 functions per minute has then been adjusted downward by
a factor of between 0. 5 and 0. 6 since all functions will not "peak" at the same time.
The resulting functional activity of 15-20 per peak minute does not include the func-
tions of route verification (part of Function G) and the rapid and continuing surveil-
lance of all aircraft for random conflicts (Function H-2). It is believed that heavy
reliance is placed upon the pilot for accomplishment of these functions.

One significant aspect of the functional activity analysis are the appar-
ent larger load on the Inbound Ground Controller although no "weighting" of the
complexity of the various functions has been attempted. The GCS conflict load
represents primarily the need to "check" or detect conflicts and should not be
interpreted as actual conflict occurrence. This conflict load (Function H) is com-
parable to the sum of the Departure plus Arrival Loan (Functions A through G ex-
cluding Route Verification).

One may well ask how the controller can handle such a load. Possible
factors contributing to this capability include delay of non-critical functions;
knowledgeable pilots familiar with O'Hare (low G. A. levels); and, perhaps most
important, the ability of a controller to remember, select, collect, and interpret
visual data (A /C orientation, markings, movement, etc.).

In periods of low visibility when the benefits of a semi-automated sys-
tem would be greater, the data processing system and displays must provide as
mich support to the controller as possible. This support is envisioned as provid-
ing extensive capability for conflict detection and function scheduling so that con-
troller attention may be directed toward the highest priority functions. With such
an approach functions will not disappear. Their need will instead be determined
within the computer (with controller override) so that repeats of functions or

surveillance for conflicts can be substantially reduced. For example, in the R/W
crossing conflict the controller needs simply a GO/NO-GO indication; with proper
surveillance data and processing the need for controller surveillance of all R/W
crossing situations may be substantially reduced. This rationale has been used to
develop an estimate of the functional activity required of the controller with a
semi-automated system and is shown in the last column of Table 4-3. It has been
concluded that such a system could reduce the functional activity load to approxi-
mately 2/3 of that in the present system under good visibility. Comparison with
the present system under poor visibility conditions cannot readily be made; how-
ever, it is believed that the workload reduction benefits will be even more substan-
tial.

SECTION 5 - DEVELOPMENT OF A LOCAL
CONTROL SYSTEM (LCS) CONCEPT

5. 1 INTRODUCTION

The semi-automated Local Control System (LCS) will provide the Local
Controller(s) with improved data surveillance, data processing, and display capa-
bilities for increasing runway capacities, reducing his workload, and providing ad-
ditional safety margins under both VFR and IFR conditions. The proposed concept
is one wherein measurement of both position and velocity information is used to
predict future aircraft position. This prediction capability is then used within a
computer to satisfy a variety of functions such as conflict detection, spacing con-
trol, R/W crossing control, etc. The outputs to the controller in this semi-auto-
mated concept are expected to range from simple GO/NO-GO types to available
time indications as well as recommendations for specific action (speed change for
second arrival, etc. ).

The proposed concept of this real-time system is still under develop-
ment; the emphasis of this working paper is therefore directed primarily toward
the requirements dictated by the semi-automated concept.

The LCS system is that described in the Statement of Work as the RASE
(Runway and Approach Surveillance Equipment). It should include, however, all
components necessary for a complete system from sensors to displays.

5. 2 REQUIREMENTS ESTIMATION

5. 2. 1 General

The Local Control System differs from the Ground Control System
(GCS) in that the traffic is more "ordered" and predictable. In addition, the num-
ber of possible aircraft routes is appreciably smaller than in the GCS. These dif-
ferences may therefore permit, and for some functions require, that the informa-
tion presented to the controller is more than a GO/NO-GO type of indication.

Specifically, the apparent needs for Spacing Control (Function F) are such that a
computer-derived recommendation for a speed change would appear desirable.

As in the GCS, an Aircraft Movement Profile has been used to esti-
mate the required prediction intervals and sensor performance requirements. A
summary of these profile characteristics is presented in Table 5-1. It should be
noted that this table is by no means complete; additional data is highly desirable if
proper algoithms are to be developed for the actual system.

To illustrate the several decision-making functions which could be ex-
pedited by a semi-automated LCS, four separate cases may be cited. These are:

Case 1 - Taxiway/Runway Crossing Control - Input to GCS from
Function J

Case 2 - Arrival/Departure Sequencing (Separate Crossing Runways) -
Functions L-l and L-2

Case 3 - Control of Arrivals on Intersecting Runways - Function L-3

Case 4 - Arrival/Departure Sequencing during mixed operations on the
same runway - Function K

The functional identification of these cases are set forth later in this
section under the several types of possible conflicts. It should be noted that other
cases also exist.

Examples of the above four control situations are shown in Figures
5-1, 5-2, 5-3, and 5-4 for O'Hare Airport. All have been observed during our
work for TSC. In Case 1, the Departure Ground Controller must decide when to
release an aircraft across the active runway. Cases 2 through 4 involve only the
Local Controller.

In Case 2 the release of Departures (Clear to Takeoff) by Local Con-
trol is based upon the status of the Arrival runway AND the intersection. The
most common method of release appears to be based upon visual recognition of

CD
U

O'Hare measurements-All
R/Ws

Dependent on R/W configu-
ration and Arrival load

Heathrow data (74+139 AC)

Takeoff speeds 120-180
knots

Dependent on "vector"
given

150 knot velocity assumed

Heathrow velocity data

(21 + 59 AC)
O'Hare data - 210 A/C;

R/W dependent

bfi
(3

25-35E

[ 200-1
J 300 j

oo co

CO CO
<N CM
1 1

in t-

os in

CO Q

CO o

250E

240E

220E

[210
1 195

01 .-.

o o>
to * M

5 &

200-400

[5000]
|_8000j
>1500

13 , 500/
25,000
7,500/
9,000
3,300/
4,000
2,900/
700 2

3 , 000/
6,000

5-.
CD

CD CD

12-73
0-120

20-56
23-50
0-180

o
o

T3 cu

1X1

<N* O ■>*

<7>

bC
>

«3

co oo m

CO CO CO

54-100*
30-40*

15-18*
15-3*
38-52

01
0>

a
1

E-l
O

g
2

R/W Entrance Time 1

R/W Hold Time (T 1JU )
ldn

Takeoff Time (STR-"OFF")

CD
CO X

■"a .2

0) ."S

be a

Jh CD >—

lis

2 1 I

<
>

Approach Time (OM-2nmi)

Landing Control Interval
(2 nmi to MM)
MM to R/W Threshold

Threshold/Touchdown

Threshold/Turnoff

Touchdo wn/T urnoff

o a

u_. 5H O +J

£o

OTHER CASES

Occasional Arrivals

of Potential Conflict

Figure 5-1. Arrivals on Intersecting Runways

OTHER CASES

Departure Queue

Figure 5-2. Arrival /Departure Sequencing Mixed Operations on Same Runway

Departure A/C going to 9R

Figure 5-3. Typical Taxiway /Runway Crossings

OTHER CASES

9R(D) - 14L(A)
27L(D) -32L(A)
32R(D) -22R(A)

Location of potential conflic

Figure 5-4. Arrival /Departure Sequencing Separate Crossing Runways

an Arrival passing through the intersection, * or "marking" the time when the
release command can be given. This method of release of a Departure after an
Arrival works well in good visibility; release of a Departure before an Arrival is
not as efficiently accomplished with visual cues.

In Case 3 we have observed situations where occasional Arrivals will
use a runway other than the primary Arrival runway. The Controller must prevent
conflicts at the intersection of the two runways. The prediction of this possibility
cannot be made to a high degree of accuracy and can represent a high risk situation.

In the mixed operations of Case 4 (Arrivals and Departures on a single
runway) the Local Controller must release or clear an aircraft from the LC
Departure Q to the runway (Function A) and then clear it to takeoff (Function B).
These instructions may in some cases be combined in a single "contact". The
Local Controller follows a similar procedure in performing this function to that
described in sequencing Arrival/Departures on intersection runways except that
the margin for error is reduced and the effect of pilot response time becomes more
significant.

The common parameter in these Controller decisions is the need for a
prediction of a "time" at which an event will occur — for example, an Arrival reach-
ing an intersection. In the absence of any significant tools to make this prediction,
the capacity of the runways must suffer in order to maintain adequate safety levels.
If simple and accurate prediction methods are available to assist the Controller,
both capacity and safety can benefit.

*A "Heavy" Arrival may restrict usage of some intersections to 2 minutes after
passage of the "Heavy" due to wake turbulence effects.

To predict aircraft future position, velocity accuracy is appreciably
more important than position accuracy for runway surveillance purposes. The
velocity parameter becomes of even greater significance when periods of decelera-
tion or acceleration occur. From rough position and accurate velocity data, a
prediction may be made of the earliest possible time an aircraft can be at a future
location, i. e. , an intersection. Continuous computation of this minimum predicted
Arrival time can then be used to establish a "denial window" (or control red lights)
for the particular operation involved.

The wide range of variables (aircraft type, pilot differences, turnoff
locations, weather, etc. ) produce a wide range of runway occupancy values which
cannot be readily estimated by the controller.

In Appendix F, the aircraft movement profile for landing aircraft has
been examined. Theoretical and experimental results indicate that substantial
benefits could be obtained through the use of prediction techniques for Runway
Crossing control purposes. Sensor performance requirements for the above con-
flict as well as other conflict types are developed in paragraphs 4.2.3 and 5.2.3.

In the proposed LCS, velocity measurements are of major importance.
What is even more important is the use made of this data — in many cases it must
be processed within a computer to produce a "time" parameter since the use of
speed values by themselves or even with position data is highly questionable.

5. 2. 2 Functional Requirements and Operational Logic

The functions to be performed by the proposed semi-automated Local
Control System have been derived from a detailed study of existing operational pro-
cedures and problems. The control functions have been classified into those per-
formed for Departures, those performed for Arrivals, and those Common to both
of the above types of operations. Four major functions have been identified for
Departure aircraft. These are:

A. Clearance of aircraft from Departure Q to runway

B. Clearance of aircraft for takeoff

C. Departure routing control

D. Handoff to TRACON

Four control functions have also been defined for Arrival aircraft.

E. Acceptance of handoffs from Approach Control

F. Spacing control

G. Landing control

H. Handoff to Ground Control

The Common control functions are as follows:

J. Runway status monitoring

K. Single runway conflict management

L. Intersection runway conflict management

These control functions are summarized in Table 5-2; in addition, the
interfaces required with the other portions of the ATC system are indicated. The
sequence of events and/or interacting functions have also been indicated in order
for each of the functions. A qualitative identification of the type of data required
by the controller is indicated in this table. In addition the estimated performance
requirements which are developed later in this section have been summarized on
this table.

The operational logic or interaction between the 11 required control
functions of the semi-automated Local Control System is depicted in Figure 5-5.
On the left side of this figure are those control functions dealing with Departures
while the right side of the figure shows the control functions performed for Arrival
aircraft. In the center of this figure the conflict management functions (K and L)
and their associated sub-conflict types are shown to illustrate the manner in which
they interact with the functions performed for Arrivals and Departures respectively.

•3

p a

1 "

i 1 l in

|— 1

oijo

1 a in

S|j

!-'

isia

eeFur

ee Fur
5-10

ill

!.'

1 1 1 1 luf

1 1

s. B

* 5

■t s

a 1 - 1

1 1

?l *

1 1 1

I 1

£ OS ■*

1 p

il" 1

1 1 1

2 P

°l <3

o §■ |

1 *i

o ^

6 a

z ? I

a -0

S y

"a- t^

1 -sir

I||f

L ff u £!

| £

<£ i5 ~ — 3 ! E-

< 1

d « 5 -5

o .'S 3 1 ? 6 « .§> S

C at R/W Take
igle R/W Confl
Previous Dep (

Previous Arriv
ersect.ng R/W
Arrival (L-l)
Departures (L-
p Routing (As;
cognition of"!

glfc

<2|I

<5 1 ,S<2

^1"!

!!_,.

■o o

II 1

£<S

-1

| g]

u 1

%°

8 a

M--

1 2- a.

ill

«2|s

I la-
.III

III?

filial

i — i—

Coverage out to 5 nm
° a =1.6fps 2

(1) For Dep entering R/WHdg
of A/C at R/W Start

2- 2

1 jg.i

U
.1 §-«

Presence Only

si iii i

a.IU

s ; 1

-
- 8

Airborne Location; Predicted Time

Over Threshold
Predicted Time at Crossing; Estimated

Time at Crossing ( Arrivals); Turnoff

Recognition/ Prediction
Estimated Time at Crossing (Deps);

Takeoff Recognition/Prediction
Runway Occupancy; Turnoffs?

Predicted Time Over Threshold
TaJceoff Recognition/Prediction
From Wake Turbulence Sensors
Turnoff Recognition/Prediction
Predicted Time Over Threshold
Turnoff Prediction/Recognition

Predicted Time at Crossmg (t + 60)
Estimated Crossing Time of Arrival
Estimated Crossing Time of Departure
Estimated Crossing Time of Departure
Predicted Time at Crossing

For Input to Functions K&L

For R/W Crossing Control and Functions K&L

For Functions K and L

S ||

1
1 £ £

K Single R/W Conflict Mgmt
K-1 R/W Entrance Delay

(Next Arrival)
K-2 Takeoff Delay (Previous

K-3 Takeoff Delay (Wake

Turbulence)
K-4 Takeoff Delay (Previous

Arrival)
K-5 Arrival (Previous Operation )

L Intersecting R/W Conflict Mgmt
L-1 Takeoff Delay (Arnval)

L-2 Takeoff Delay (Departure)

This figure depicts the overall logic between the various control functions; the de-
tailed examination of each function provides further breakdown of the operational
logic in the section on Performance Requirements.

It should be noted that the function of dual approach monitoring cur-
rently performed in the IFR room has not been included in the proposed system.

5. 2. 3 Performance Requirements

5. 2. 3. 1 General

The following sections examine each of the functions to be performed
by the LCS in order to determine the performance requirements or characteristics
of the data needed by the Controller and/or data processing system to properly
perform the specified function. Primary emphasis is on the desired character-
istics of the surveillance sensor (s), recognizing that there will, of course, be
other inputs to the data processor. The information required is set forth in oper-
ational terminology; these terms must then be related to the physical parameters
or maneuvers of the aircraft which will be determined by the surveillance sensors.
For the 11 functions of the LCS the information needed is:

OPERATIONAL DATA

Link Occupancy/Binary Heading

Movement Detection

Turn Recognition/Heading

Airborne Position

Airborne Velocity

Airborne Heading

"OFF" or Predicted "OFF" Time

Turnoff Recognition/Prediction

R/W Occupancy

Predicted Time Over Threshold

Predicted Time at Crossing

Estimated Time at Crossing

INPUTS FROM
SURVEILLANCE SENSOR(S)

Position

Velocity

Heading or Position Velocity

Position

For Heading Computation

Position, Velocity, Acceleration
Position, Velocity, Heading
Presence

Airborne Position/Velocity
Airborne Position/Velocity
Ground Position, Velocity
Acceleration

Only a few of these operational data elements are needed for each func-
tion; the ones selected are those believed to be of primary significance for replac-
ing or supplementing the process where applicable. Current prediction capabilities
based upon position vs time (for example, "location above the horizon" vs time for
an incoming Arrival) are believed to be quite limited in the present system.

Resolution performance requirements have not been discussed in the
specific sections which follow since aircraft under Local Control are well sepa-
rated except at their entry into, and exit from, the area of responsibility of the
Local Controller. No need is seen at this time to resolve or track the individual
aircraft in the Local Control Departure Q. However, resolution of an aircraft
leaving this Q will require resolution capabilities of perhaps 100 ft to 200 ft from
those in the Q area. Moreover, tracking of aircraft on the runway must be achiev-
able with adjacent A/C on the parallels (approximately 400 ft between centers).

5. 2. 3. 2 Clear Aircraft from Departure Q to Runway (Function A)

The movement of an aircraft from a "stopped" condition in the Local
Control Departure Q to the point where the aircraft is on the runway and pointed
in the take-off direction has been found to take about 33 seconds. * An indication
of "demand", or that this function is to be performed by the Local Controller, is
usually based on the fact that there is one or more aircraft in the Local Control
Departure Q. However, it should be noted that in certain cases of bad weather
some aircraft may be pushed to the side of the Local Control Departure Q area
(while they are waiting for weather to reach company minimums) and other depar-
tures in the Q will bypass these waiting aircraft. However, in general the order
of aircraft in the Departure Q is established by the hand-off process of the Ground
Controller and, unless the special situation as described above takes place, the

♦Reexamination of the data collected at O'Hare, based on a sample of 88 aircraft
and most of the runways, indicated a value for this parameter of 33 seconds with
a standard deviation of 12. 6 seconds. The range of values was from 12 seconds
to 73 seconds.

Local Controller knows which aircraft is at the head of the Local Control Depar-
ture Q. Before releasing the aircraft from the Departure Q to the runway takeoff
location, a Local Controller must also know that the runway takeoff area is avail-
able, i. e. , usually by simply noting that the previous departure has left.

Prior to issuing the clearance to the runway, Function K-l must be
performed, i.e., a single runway conflict check must be made if the particular
runway is also being used for Arrival aircraft. If such is the case (i. e. , an Ar-
rival aircraft for example has been accepted by the Local Controller on this run-
way), it will be necessary to estimate whether sufficient time is available to clear
the Departure to the runway and to release it for takeoff, while maintaining ade-
quate separation between the Departure and the incoming Arrival. This conflict
check is discussed more fully under Function K-l.

After the aircraft has been cleared to enter the runway it will be nec-
essary for the surveillance and data processing system to recognize aircraft start-
up from the Departure Q and movement out onto the takeoff end of the runway. It
is proposed that Link Occupancy and Movement Detection processes will be satis-
factory to verify that Function A is underway. The performance requirements are
expected to be similar to those discussed under the Ground Control System, namely,
one sigma values are about 3 fps in velocity. If velocity is obtained from position,

it is estimated that a = 10 ft to 25 ft depending upon the sampling rate employed.

5.2.3.3 Clearance of Aircraft for Takeoff (Function B

While under some conditions aircraft can be cleared for takeoff at the
same time they are released from the Departure Q to the runway, the more preva-
lent mode of operations is to release the aircraft for takeoff after they have moved
to the runway end point. The time at which this function is to be performed can
therefore be recognized by the fact that the aircraft is indeed at the runway take-
off point. Function B may be considered to have been completed when the aircraft
has begun its takeoff roll. Depending upon the runway configuration in use, various

types of conflict checks must be made by the Local Controller before the Departure
is released for takeoff. One set of checks involves those dealing with the opera-
tions on the particular runway to be used by the Departure; these have been classi-
fied as single runway conflict checks and are described later under Function K.
The other type of conflict checks (and these appear to be more prevalent in the op-
erations at O'Hare) are those dealing with operations on intersecting runways.
These are more fully described under Function L.

Recommended heading, or Departure Routing information, will be given
by the Local Controller to the pilot (often in the same contact that is used for "clear
to takeoff"). It can be seen, therefore, that Function B interacts with Functions C
(Departure Routing Control), K and L. The performance requirements of Function
B, insofar as recognition of the aircraft being at the takeoff point, are approxi-
mately the same as those set forth for Function A, with the exception that rough
indication of aircraft heading information appears to be desirable. It is estimated
that most aircraft will take between 10 seconds to 15 seconds to make a 90 degree
turn such as that required when an aircraft turns onto the runway. If all other
criteria have been satisfied, it can be seen that the Local Controller could release
the aircraft for takeoff during the time that the aircraft was completing its turn
onto the runway; such a process might save 4 seconds to 6 seconds in the runway
occupancy time of a Departure. We have estimated that aircraft heading informa-
tion to perhaps 20 degree accuracy would be useful for this purpose. The velocity
accuracy requirement is established by the fact that the Controller might wish to
have information showing that the particular aircraft has indeed stopped, i. e. , not
started to take off before the release signal has been given. The accuracy require-
ment here is established by the need for Movement Detection or recognition and is
estimated to be of the order of 5 fps. The position accuracy (exclusive of that re-
quired to estimate velocity) is less demanding than that of Function A; a value of
perhaps 40 feet to 50 feet should be sufficient.

Position information is not needed for recognition of the "start-to-roll"
process; the velocity information requires an accuracy comparable or slightly

higher than that previously discussed. The more accurate this process the faster
will be the response time in recognizing the beginning of the takeoff process.

5. 2. 3. 4 Departure Routing Control (Function C)

Since one of the major functions of the Local Controller is to provide
separation between successive departures, it is desirable to assign different head-
ings or vectors to successive departure aircraft. The information needed by the
Controller, therefore, is the departure (vector) heading followed by the previous
2 to 3 departures as well as the "off" time of these aircraft. From this informa-
tion the Controller may then select a different vector /heading in order to increase
departure separation as much as possible early in the takeoff process. When
"heavy" aircraft are involved, wake turbulence effects are, of course, a separate
constraint on this routing process. Accurate position and velocity information is
of less importance in this departure routing and control function than is the meas-
urement of aircraft heading in order to verify that the departure is indeed following
the assigned vector heading. Estimates of position accuracy of between 200 feet
and 400 feet, velocity accuracy of 15 feet to 20 feet per second (about 10 knots)
should be sufficient for routing verification. Aircraft heading information to a one
sigma value of perhaps 10 degrees represents a preliminary estimate of the direc-
tional data desired for this function.

Pilot verification of departure route assignment is currently used;
handoffs are often made during the time that the aircraft is turning to its assigned
heading. This procedure may be acceptable in the semi-automated LCS. However,
data entry of route followed by the aircraft, if needed, then must be done manually.

5. 2. 3. 5 Handoff to TRACON (Function D)

We may consider that Function B has been completed when the aircraft
lifts off the runway and that Function D begins at this time. Handoff of the Depar-
ture to the IFR room or TRACON does not usually take place, however, until the
Local Controller has verified that the assigned departure routing is indeed being

followed by the aircraft. Function C therefore will interact with this function for a
period of from perhaps 20 seconds to 60 seconds depending upon the aircraft equip-
ment type as well as the assigned departure routing. No accurate sensor informa-
tion is required at the time of handoff insofar as the Local Controller is concerned
since the evaluation that separation standards are being maintained is part of Func-
tion C. Information on aircraft "Off" time, but not position or velocity, is needed
to provide an input to Function J, Runway Status Monitoring. This information can
be used by the Local Controller in performing the single runway conflict check or
to assist him in specifying the release time of the next departure. The recognition
of "off" time or "predicted off" time for a departure has been discussed in Func-
tion K-5.

5. 2. 3. 6 Acceptance of Handoffs from Approach Control (Function E)

Handoff of arrival aircraft from Approach Control position usually
takes place in the vicinity of the outer marker, 4 nmi to 6 nmi from runway thresh-
old. The ARTS BRITE display in the cab is the tool used by the Local Controller to
recognize aircraft position and identity at the time of handoff. Performance of this
function, therefore, simply requires sufficient position accuracy for the Local Con-
troller to readily detect the incoming arrival at the time of handoff. A value of be-
tween 600 feet and 1800 feet has been estimated for this function; velocity informa-
tion is not needed until Spacing Control is to be performed.

5. 2. 3. 7 Spacing Control (Function F)

Normal procedures call for minimum separation between Arrivals of
three nautical miles while under radar control. In poor visibility conditions, when
visual approaches are not possible, the Local Controller is responsible for longi-
tudinal separation via the ARTS BRITE in the cab. For the purpose of this study,
that mode of operation will be assumed to continue with no change due to ASTC
equipments.

5. 2. 3. 8 Landing Control (Function G)

Issuance by the Local Controller of the "clear-to-land" instruction
under current day practices and in visual conditions appears to occur over a wide
range of time intervals. In some cases the aircraft is at the middle marker while
in others it might be 2 miles to 3 miles out. If the Local Controller does not have
the aircraft in sight by the time it is close to the missed approach point, the Con-
troller must issue missed approach instructions unless the pilot has reported that
the runway lights are in sight. In any case, the termination of an approach by the
issuance of the "clear to land" message cannot take place any later than when the
aircraft is at the middle marker or the missed approach point. During the Land-
ing Control function, conflict checks must be made on a single runway basis (see
Function K-5), as well as possible conflicts arising due to usage of intersecting
runways (see Function L-3).

No special sensor requirements have been established for Landing Con-
trol except those dictated by the two conflict management functions K and L. Air-
craft location at the middle marker will, of course, terminate the time at which
Landing Control can be exercised. However, during the last 20 seconds to 30 sec-
onds of the pre-touchdown phase of the arrival aircraft, it is anticipated that the
conflict management jobs performed on the computer may still be in process so
that special instructions may be given to other aircraft on the surface if necessary.

5. 2. 3. 9 Handoff to Ground Control (Function H)

Landing aircraft may occupy a runway from periods of between 40 sec-
onds and perhaps 60 seconds. Were it not for the scheduling and conflict manage-
ment of other aircraft the handoff process to the Ground Controller could take place
any time during the period that the aircraft is decelerating on the runway. In prac-
tice, however, handoff to the Ground Controller is performed at a time close to
aircraft turnoff from the runway. The Local Controller in many cases recognizes
A/C Heading Change and gives an anticipatory "handoff".

The sensor requirements, therefore, for the handoff process are pri-
marily those established for conflict management purposes to be certain that the
runway is indeed clear for other operations. Estimates of the performance re-
quirements for this function are set forth under the conflict management functions
K and L, discussed later.

5. 2. 3. 10 Runway Status Monitoring (Function J)

The function of this computer job is primarily one of providing inputs
to the conflict management functions K and L. However, it is also required to
provide inputs to GCS Conflict Management (H-2). In order for the ground control-
ler to release a departure to cross an arrival runway there should be sufficient
time for the crossing aircraft to clear the runway before the next arrival approaches
the crossing intersection. The time elements for crossing are estimated as follows:

Duration (Sec)

Communication to Pilot 5-7

Pilot Reaction Time 0. 8

Runway Crossing Time* 20-40

Totals 25.8-47.8

If the taxiway crossing point is at the mid-rollout point (i.e. , about
20 seconds after the arrival crosses the threshold) and 20 seconds of safety buffer
is allowed between the crossing aircrafts clearing and the arrivals reaching the
intersection, a crossing should be withheld if an arrival is within 50 seconds of the
threshold. Allowing 5-10 seconds latitude in the decision making, the predicted-
time -over- threshold should be available 60 seconds out from threshold. At
appraoch speeds of up to 150 knots the GCS coverage of 2.5N miles from threshold
is established.

*Reexamination of the data collected at O'Hare indicated a mean of 30 seconds
with a standard deviation of 6 seconds. The range of values was from 18 seconds
to 38 seconds.

5. 2. 3. 11 Single Runway Conflict Management (Function K)

Operations conducted on a single runway make it necessary for the
Local Controller to evaluate five types of conflicts on a regular basis. These five
conflicts are listed in Table 5-3 which also provides an indication of which aircraft
will normally be given priority (A/C #1) as well as a qualitative estimate of the in-
formation needed by the Controller for decision-making purposes. The three main
decisions made by the Controller under normal conditions are:

For Departures

Clear to enter runway - part of Function A

Clear for takeoff - part of Function B

For Arrivals

Clear to land - part of Function G

Accomplishment of these decisions in an optimum manner requires in-
formation on both surface as well as airborne aircraft. Each of the five conflicts
will be discussed in detail below.

1. Conflict K-l R/W Entrance Delay/Next Arrival

In order for the Local Controller to release a Departure from the
Local Control Departure Q onto the runway there should be sufficient time for the
outgoing aircraft to be clear of the runway ("OFF") before touchdown of the next
Arrival. The time elements involved are estimated as follows:

Duration (Sec. )
Communication to Pilot 5-7

Pilot Reaction Time 0. 8

A/C Movement Time (to R/W) 25-35
Communication to Pilot (Clear to R/W) 5-7

Pilot Reaction Time 0. 8

Start-to-Roll/"OFF" Interval 30-50

Total 67.6-101.6

5-21

Q
o

3
CD

3
o

o
o

3
o

o
o

o
8

2 O

Fh ^

•o £
S%

.2 H
73 >

CD !>
Jh ^
ft tf

.5 o

-a £
.2 ^
.2 h
73 >

CD t>
^ \

ft tf

Q
u

•J

.5 <y

° S
<3 5

CD \

2 tJ

3 5

&£

CD \

Q «

2 £
&£

CD \

Q tf

CD \

3
Jh
O

3
5h
O

Q
o

T3
CD

CD
>

o
.5 o

"O |
2^

ft «

Sin

o O

Pq CD

O 1*

- ft

CD
&

s
o 3

•13 O

O 'O
O
CD h

tf ft

s 3

S-i Sh
3 3
H H

o
.5 °

rQ CD

.2 ^

CD
g

H
O

§•2
11

T3 O
CD O
f-i CD

ft tf

o
3 3

s
o

■g

CD
|

3
o

<
0)

3
U
O

as
ft

Q
be

o
u

cr
Q f

s ^

Q §
o V

<D CD

3
>>£

d 3

Q £
St) H
o a,

CD S

a «

& °

3
O

V
u

ft 3
\ O

"C |

Sh ft

< o

■*

S -B

s §

"el H

r ^

2 «

§*

1 1

Rounding off these values we may estimate that between 70 seconds and
100 seconds are needed with the present voice system; this possibly could be re-
duced by 10 seconds if a "signaling" approach (red/green light) was employed.

If "t " is the predicted "Time over R/W Threshold" for the Arrival

It has been estimated* that the ability of a pilot to control his speed
from the Outer Marker to Threshold is such that the standard deviation of his time
over threshold is about 5 seconds. If this value is also used for a (t )and the upper
value of 100 seconds is selected from the above relationship, then

t > 110 seconds
P

Since landing speeds of aircraft range from 100 knots to 150 knots

(167 fps to 250 fps) the arrival aircraft must be no less than 18, 370 (110 x 167) or

27,500 (110 x 250) feet from threshold for these two speeds (three nmi to five nmi

out). This essentially defines the required coverage area for prediction of "time

over threshold".

Using the prediction accuracy formulas of Appendix E, we have

at = -- cr due to position error

1 v A
a
at = t — due to velocity error

where these are the two components of a (t ) and it is assumed that no appreciable
braking or acceleration takes place during the last 80 seconds to 100 seconds be-
fore threshold crossing. If a is taken as one second then, for the slowest air-

craft, we have a = 167 ft. Taking cr =5 seconds and t = 100 seconds the re-
x t 2

quired velocity accuracy is a = 5(167)/l00 = 8. 3 fps.

*Astholz, et al. , "Increasing Runway Capacity", Proceedings of IEEE, March 1970

2. Conflict K-2 Takeoff Delay due to Previous Departure

Since R/W occupancy time for a departure will range from 20 seconds
to 56 seconds, and the time required to move a Departure from the LC Departure
Q to the takeoff point averages 33 seconds (range 12 seconds to 73 seconds) (see
time estimates in Table 5-1) it is expected that "rolling" departures will cause
takeoff delays until the first aircraft is clear ("OFF") of the runway. An indica-
tion of this status can be obtained by a pilot report. Measurement of this change
in aircraft status appears difficult to accomplish. On the other hand, prediction
of "OFF" time based on aircraft velocity and possibly acceleration measurements
while on the runway may be desirable. Assuming that the second departure can be
cleared-for-takeoff no sooner than 6 seconds to 8 seconds before the first aircraft
is actually "OFF", the prediction interval of interest is of the order of 10 seconds.
Ignoring for the moment wind effects (which will be minimal in most low visibility
conditions), the requirement becomes one of prediction of the time at which normal
takeoff velocity is reached. Since

t = — for linear acceleration

we may define the two components of prediction error (due to velocity and acceler-
ation errors) in the same manner as for the position/velocity relationship t = — .
This, of course, assumes independent Gaussian processes for "a" and "v". The
two components of error are

Values of a and o equal or less than 1 second appear desirable.

With a = 16 fps (0. 5g) a value of o = 10 fps would result in cr = 0. 8 second.

V 2

Acceleration measurement uncertainty of 1. 6 fps (o ) would result in a = 1

A n -i c\ ^

second ( — J at the 10-second prediction interval. This prediction capability

could result in perhaps 6 seconds to 8 seconds time saving for departures. The
impact of aircraft equipment type on the variations in takeoff characteristics need
further investigation.

5-24

3. Conflict K-3 Takeoff Delay/Wake Turbulence

Separation between departures must consider wake turbulence effects
due to "heavy" aircraft. Wake turbulence measurement sensors can plan a signifi-
cant role, it is believed, in reducing departure delays due to this phenomena. No
special requirements on the aircraft position, velocity, or acceleration sensors can
be defined at this time. While wake formation may possibly be correlated with air-
craft equipment type and velocity, wake dissipation takes many seconds and may
not be readily predictable. Data from wake turbulence sensors should be integrated
into the Local Control System for use in this function.

4. Conflict K-4 Takeoff Delay/Previous Arrival

Immediately after an Arrival has crossed the runway threshold, the
controller can perform Function A (release of aircraft from Local Control Depar-
ture Q to runway). Runway occupancy time by Arrivals is longer than that of De-
partures and ranges from about 38 seconds to 52 seconds at O'Hare except when
aircraft use the R/W for taxiing (R/W 22 L). Under present procedures Departures
are not cleared for takeoff until the Arrival is clear (or almost clear) of the run-
way; the Controller in visual conditions does give anticipatory clearances. Ideally,
a "runway available" signal to the Controller perhaps 6 seconds to 10 seconds prior
to the Arrival being actually clear of the runway appears desirable to reduce depar-
ture delays. Relaxation of the rule that only one aircraft can be moving on the run-
way at any instant of time could increase this interval to perhaps 10 seconds to 15
seconds since the minimum total time from release to takeoff will be of the order
of 40 seconds. Prediction of the aircraft turnoff maneuver of the Arrival could
perhaps be accomplished by recognition of change in aircraft heading in many cases.
For low angle turnoffs (where the angle is perhaps 30 degrees) a standard deviation
of heading change of perhaps 5 degrees to 10 degrees (o ) is believed to be desirable.

This "Turn Recognition" process wherein

Q= tan -

x = Position component orthogonal to runway
y = Position component along runway

will be influenced by the statistical characteristics of the sensor geometry with
respect to the runway as well as the turnoff geometry. Additional study and/or
simulation will be required to ascertain the ability to recognize "turns" with a
minimum of time delay.

At this time the safer criteria appears to be one of recognizing aircraft
occupancy of the turnoff link (and clear of runway); i.e. , Link Occupancy plus
Movement Detection. The latter process is desirable since the turnoff links are
short and, unless the aircraft is detected as "moving", the system cannot be sure
that the arrival aircraft is completely clear of the runway. It should be recognized,
however, that this criteria will hamper overall response time.

5. Conflict K-5 Arrival with Previous Operation

The preceding four conflicts, K-l through K-4, have dealt with delays
to Departures. Under conflict K-5 we shall consider the possible impact of the
preceding operation on an incoming Arrival. While under most circumstances the
incoming Arrival must be given priority, there may be situations where "permis-
sion to land" should be denied.

Three situations will be examined under this conflict. In the first, a
conflict may exist between an Arrival and a Departure at the runway start point but
not moving. This has been observed in the data collection effort. In this case, the
Departure was instructed to continue across the runway to clear the threshold for
the Arrival. The information needed by the Local Controller is the Predicted Time
over Threshold for the Arrival while for the Departure aircraft he needs heading
information, i. e. , is the Departure pointed along the runway or can it quickly
"exit" the runway if necessary. This latter option is not possible at all takeoff
points, i. e. , it can be done on 27L and 32R, for example, but not on 32L and 9R

unless the aircraft is moved onto the grass. * The information needed by the con-
troller is the "Predicted Time over Threshold" (for the Arrival) similar to that
needed for Conflict K-l, except that the prediction interval will probably be of the
order of 50 seconds to 70 seconds rather than the higher values required in K-l.
We shall use the same position and velocity accuracy estimates for this conflict as
in K-l, recognizing that somewhat better prediction capabilities will be achieved.
The information required on the other aircraft is its relative heading with respect
to the runway and that a potential runway exit is available. This requirement
appears to imply "Turn Recognition" capabilities when the aircraft moves out onto
the runway.

In the other two examples of K-5 wherein a "rolling" Departure or Ar-
rival is on the runway with an Airborne Arrival near the Missed Approach Point
(MAP) it is believed that the former cannot take place unless the Departure aborts
its takeoff (see Note 2 on Table 5-3). When the previous Arrival is slow in clear-
ing the runway it may be necessary to issue a Missed Approach instruction to the
incoming Arrival or to inform it to "hold short" of a particular point on the runway.
It is recognized that priority should be given to the airborne Arrival; however, in
certain situations this may be impossible. "Predicted Time over Threshold" is
required data for the airborne Arrival; for the "rolling" Arrival on the runway it
is desired to have a "Turnoff Recognition" or prediction as soon as possible.

5. 2. 3. 12 Intersecting Runway Conflict Management (Function L)

Most operations conducted at O'Hare use intersecting runway configur-
ations. The location of the intersection of the runways with respect to the thresh-
old for Arrivals and the start of takeoff point for Departures is a major factor in
the decision process performed by the Local Controller. Figure 5-6 illustrates
four types of intersections based upon Arrivals on one runway and Departures on
the other. These four cases (Case I through IV) are identified as Near/Near;
Near/Far; Far/Near; and Far/Far with the first designation indicating the Arrival
runway and the second the Departure runway.

*The control flexibility offered by this pavement design at the runway ends appears
to be a desirable feature for incorporation in future runway designs.

E xomples:

27R
32R

* =Unlikely

a) Near -Near R/W Configuration

CASE JL

Departure
32R
27R *
9L *
4L

32L 27L

9R I4R

b) Near - Far R/W Configuration

c) Far- Near R/W Configuration
D

I4L 4L

22R 27R

27R 22R *

d) Far -Far R/W Configuration
Figure 5-6. Intersecting Runway Configurations

Three types of potential conflicts have been identified as shown in Table
5-4 for operations on intersecting runways. In the first, L-l, a Departure on one
runway must be released so as to avoid a conflict with either an incoming airborne
Arrival or an Arrival rolling on the runway but not yet past the intersection. In the
second case, L-2, the Departure must avoid a conflict with a "rolling" Departure
(on the other runway) which is not yet past the intersection (wake turbulence may
also be a factor in this situation). These two conflicts (L-l and L-2) represent
"Takeoff Delays" which can be minimized by the use of prediction or estimation
techniques for establishing the time availability of the intersection (or crossing).
We shall use the term "predicted" to indicate the estimated time that an airborne
aircraft will reach a particular crossing while the term "Estimated Crossing Time"
will be applied to aircraft (either Arrivals or Departures) which are "down" on the
runway.

The third type of conflict, L-3, is that occurring between two moving
aircraft and as such represents the most stringent safety requirement. In the first
example of this type of conflict a "rolling" Departure, because of delay in starting
to roll, may be in conflict with an incoming Arrival beyond the MAP. The priority
aircraft in this case is probably the Departure. The Near/Far Configuration (Case
II) is the most stringent situation. Information on the Estimated Crossing Time
(of the rolling Departure) can permit the acceptance or rejection of the incoming
Arrival. Another example of the L-3 conflict would be between an airborne Arrival
and a "rolling Arrival" on another runway which has not yet reached the Crossing.
Here the Airborne A/C has priority and the other aircraft must be given a "stop"
instruction rapidly. This situation is most likely under the Near/Far or Far/Near
runway configurations. The data needed by the Controller is the Estimated Cross-
ing Time of the ground Arrival as well as the Predicted Time at Crossing for the
airborne aircraft.

From the above discussion it can be seen that three types of data are
required for either control of the runway crossing or release of Departures. These
are:

ca
Q
u
o

to
TJ

o
o

cc
o
o

1
i

I fl

■O co

CD O

J- Sh

ft U

CO
CO

o
o

S CD

'"co .@

CO -w

J-l ^
3 «

&£

Q «

§■£

Q «

<
3 5

Q «

<
CD
C

§
>

in
o

-a
h

'3
cr

g
.2 «

T3 CD

a; o
ft O

"oa

o
u

0)
S CD

O
T3

S a;

bD
'co

a o
B.g

be
C
'co

t-i
O

CD
O

ft H

<
>>

<
O

o
>

CD
U

c
"o

'£
<

-Q
<

H
o

a of

o >

O <D

2 1

o 1

8 a

■s 5

h a

■g

ft C

\ o

1 2
1$

1. Predicted Time at Crossing - of Airborne Arrivals

2. Estimated Crossing Time - for "Rolling" Departures

3. Estimated Crossing Time - for "Braking" Arrivals

Since the prediction interval for the first data item above is expected
to be no more than 60 seconds, the required position and velocity accuracy can be
satisfied by the criteria established under Function K. The performance
requirements for the second data item above can be satisfied with the criteria estab-
lished under Function K-5.

The third data item, i. e. , the Estimated crossing time of a "braking"
Arrival at a future intersection is needed not only for Function L-3 at intersection
of runways but also needed for input to the runway Crossing Control function per-
formed by the Ground Control System. Based upon measurement of the position
and velocity of the "braking" Arrival, several estimates can be made. For a slow
moving Arrival, an estimate based on the assumption that no acceleration takes
place in the future can be made of the minimum time at which the Arrival will reach
the intersection. If this time is more than say 20 seconds to 30 seconds, then
there is sufficient time to stop the Arrival if necessary. Fast moving Arrivals,
say at 60 knots (about 100 fps) or that are within 1000 feet of the intersection,
probably must be considered as positive users of the upcoming intersection. The
estimate of time past the intersection, or Estimated Crossing Time, in this case
must be delayed until the Time-to-Go of the Arrival is perhaps 10 seconds or less.

5. 2. 4 Operational Requirements

The operational requirements for the Local Control System will be
specified in terms of the responsibilities of a single Local Controller recognizing
that at O'Hare for example there are essentially two almost independent sets of
runways. Of primary interest is the maximum traffic that a single Local Control-
ler will handle both during the "busy" hour as well as during the short term (3-
minute to 5-minute) peaks. This traffic load will be dependent upon runway con-
figuration. For a single runway serving just arrivals it is estimated that four

aircraft could be simultaneously under control, three airborne (OM, OM-MM,
near threshold), and one on the ground near turnoff. A separation value of 2 nmi
has been used as an estimate of possible future standards. Similarly there may
be four simultaneous departures for a single runway, one entering the runway, one
"rolling", and two airborne (prior to handoff). From these estimates and the fact
that 2-3 runways may be active at one time we can estimate the number of simul-
taneous operations in progress. This represents a short term peak load.

While the present hourly quota system of 135 A/C for O'Hare implies
about 70 ope rat ions /hour for each side of the airport, the tower is currently (sum-
mer 1974) handling from 140-170 ops/hr. It is recommended that the LCS be sized
to handle 100 ops/hr per Local Controller. We may summarize the traffic load as
follows:

Number of Active Runways 3

Number of Simultaneous A/C under Control 10-12

Busy Hour Ops Rate (Future) 100/hr

The LCS must be capable of operating in a variety of runway configura-
tions. Mixed operations on each of the three active runways must be achievable.
In addition the system must be capable of handling a variety of crossing-runway
situations.

5. 3 PRELIMINARY MODULE DESCRIPTION

5. 3. 1 Overall Characteristics

The major components of the proposed semi-automated LCS are Sur-
veillance Sensors, Data Processor, and Displays plus Input/Output devices. These
components must be connected via dedicated communication facilities of either a
"hardwire" and/or radio nature. Independent displays are provided for the two
Local Controllers. The set of surveillance sensors may or may not be geographi-
cally independent. This gross representation of the total LCS does not imply that
some pre-processing of surveillance data cannot be done in the sensors themselves.

While the description of the LCS has been based on the use of a single
data processor, integration of this system with a similar Ground Control System
might result in a single processor for use by both systems.

Three types of surveillance sensors have been shown feeding into the
data processor. The first type of sensor would be one wherein aircraft in the
ground environment are kept under surveillance; the second would be devoted toward
surveillance of airborne aircraft on both the approach and departure flight paths;
the third sensor would be used for determination of "runway occupancy" checks on
non-cooperating vehicles. While three independent sensor systems have been shown,
it may be possible for one sensor system to perform the three types of surveillance
functions illustrated in Figure 5-7.

It is anticipated that the data processor will also perform scheduling
functions to activate on the displays the proper information for the specific function
to be performed by the Local Controller. It is recognized that a large amount of
information is currently acquired by the Local Controller by means of visual sur-
veillance techniques over a large area of coverage. Condensation of this informa-
tion, as well as proper selection of the data elements, will be a prime goal in the
concept development of the displays. It is envisioned that there will be multiple
displays/data inputs available for the Controller with cueing assistance provided
from the data processing.

5. 3. 2 Interface Considerations

The LCS must interface with the Ground Control System as well as the
ARTS system. In the latter area, it is currently envisioned that interface will be
required only for Arrival aircraft and that Departures from the LCS will be handled
no differently than the acquisition process currently performed by the Departure
Controller in the TRACON. On the other hand, arrival information from the ARTS
data base will serve to ease the acquisition problem for the airborne surveillance
sensors and also provide coarse position information for use in some of the Local
Control System functions (for example, Spacing Control).

>•

^_ UJ
Z uj

r—

1—

■■■

z
o
o

UJ Q

>>*

•*».

<a>

/From G.C.S.
» Handoffs
• R/W Cross

-J
o

>-UJ

tr o
z>

1—
z

q:
o

^ CO

</> <CO

■""^

«»

r -

UJ —

3 ^

— 1 CC UJ

i uj i

o <*>

I tn<t 1

35*

l *- m

JO Q

-J o z

5 s

o 1

CZ3 o^ 9£

> z °
Cuj ca
9= co tr

en s.

L_ J

The LCS must supply information to the Ground Control System for
handoff purposes as well as runway occupancy or prediction data to be used by the
Ground Control System in performing the Runway Crossing control function. In the
latter area, conversely, it is expected that the GCS will provide information on
taxiing aircraft that might impact upon the operations of the runways. Aircraft
that have been handed off by the Ground Control System to Local Control automat-
ically will be entered in the Local Control System data processor at the time this
event occurs. These departure aircraft essentially will be in an inactive status as
they move toward the top of the Local Control departure queue.

The block diagram of the LCS also shows possible alternate communi-
cation paths between the Controller and aircraft; these paths are of a signaling
nature and would be via control lights for such diverse purposes as releasing air-
craft onto the runway entrance, clearing aircraft for takeoff, etc.

Additional interface requirement between LCS and other portions of the
ATC system will necessitate the inputting of support data to the LCS data processor.
This may include such parameters as the runway configuration in use, inputs from
wake turbulence detector sensors, weather data, etc.

5. 4 BENEFITS ANALYSIS

5.4.1 Capacity Improvement and Delay Reduction

While the present quota system at O'Hare is 135 ops/hr. , there are
numerous occasions when the ATCT will handle between 140-170 aircraft. These
peak hourly loads are most prevalent in the summer period; the busiest hour at
O'Hare was 208 aircraft moved in 1968. Weather is the primary cause of long de-
lays. Such factors as local thunder storms forcing larger separations as well as
conditions of poor visibility represent two different weather conditions affecting
operations. In good weather, airport operational levels of 120-140 aircraft/hour
result in average delay per departure between 6. 2 minutes to 8. 5 minutes. These
results are for periods when essentially "no delay" would be reported by the ATCT.
These delays have been found to be sensitive to the active runway configuration. It

5-35

is believed that other factors such as individual differences between controllers
may also play an important role in these delay variations.

The data inputs to the Local Controller come either from the position
information on the BRITE (Airborne Arrivals only) or from visual surveillance.
These limited data inputs do not provide much prediction capability for decision-
making purposes by the Controller. It is in this area that the proposed semi-
automated LCS can provide substantial assistance to the functional activities of the
Local Controller.

This assistance would take the form of providing "flags" or signals to
the Controller as to the acceptability of a particular decision (Clear to Takeoff;
Clear to Enter Runway, etc) as well as furnishing "scheduling" recommendations.
The benefits from the LCS would consist of improvements in

Arrival/Departure Sequencing

Landing Control

Runway /Runway Crossing Control

Interfacing with Ground Control for

• Taxiway/runway Crossing Control and

• Indication of when Turnoff- Generated Conflicts can exist

These improvements should reduce good weather delays and signifi-
cantly increase the airport operational levels under conditions of poor visibility
when it normally falls between 10 percent and 25 percent of normal operations.

If a reduction of 2 minutes could be achieved in the departure delays
in good weather conditions this would result in a daily saving of about 700 x 2 =
1400 minutes based upon 700 departures taking place during busy hours. Over the
year this translates into cost savings (at $11. 23/minute) of $4. 7 million (1400 x
300 x 11.23).

5.4.2 Safety Benefits

The proposed LCS can provide substantial safety benefits by performing
many "housekeeping" and estimations functions for the Local Controller, thereby
releasing additional time for the exercise of human judgment. Such safety benefits
become of greater significance in periods of low visibility if reasonable operational
levels are to be achieved in these periods.

The operational areas wherein safety will be improved have been de-
scribed earlier in this section as well as in the discussion on the Conflict Manage-
ment function. Provision of additional information on operations in these areas on
a timely basis (when needed) can also minimize differences between controller de-
cisions and task scheduling. These factors should further reduce safety incidents
in the most vulnerable portion of the tower operations, i. e. , Local Control.

5. 4. 3 Workload Reduction

The workload of the Local Controller can be only partially estimated
from the communication traffic. When delays exist the Controller must in most
cases wait; during this interval he is continually reevaluating the situation. Table
5-5 provides an estimate of the functional activity of a Local Controller for depar-
tures (represented by "d") and Arrivals (represented by "a") under the present
system as well as in the proposed semi-automated real time control system. It is
estimated that appreciably more effort is necessary for Departures than Arrivals
under the current system. Using the values shown of 8d and (5. 5-7)a given in this
table, an operations rate of 60/hr would require the performance of 405-450 func-
tions per hour. In a peak minute perhaps 10-12 functions would require service.
This functional load does not appear tractable by a single individual. The Control-
ler therefore adapts to the situation (estimates Spacing Control, performs less
monitoring of Departure Routing, and maintains further separation to ensure no
possible conflicts can occur). Under the semi-automated concept, the functional
activity level can be substantially reduced, primarily since the computer will be

o
o

1
§

<0
h

■3
a 1
qj
P3

QJ
TO

.si?

TO "TO
5 §3
'to CO

H
<

1
to

a;
o

O
O

I
ft

<d o «?

in in u) T3 i T3
col • •

TO | TO TO

T3 T3 TO

IS rl r-i +

-o to

cm i-i

o m
n

■s a

0) QJ

jgl-O TJ T3 T3 T3

TO ^ TO TO
©

+ X5 T3 TO + "O CO
T3 toI

'O in

i bD O
f* C IS

2 TO §

1 1

H M J

c
o

o
<

«
p

<
ft

w
p

A Clear A/C to R/W

B Clear A/C for Takeoff

C Departure Routing

Assignment

Verification
D Handoff to Departure Control

<
>

E Accept Handoff from TRACON

F Spacing Control

G Landing Control

H Handoff to Ground Control

O
H
O
Z
P

o
o

QJ
hJj

S
U

K-1 R/W Entrance Delay

Takeoff Delay /Previous Operation

K-5 Arrival/Previous Operation
L Intersecting R/W Conflict Management

QJ
*h

® c-i

Q §

*h S3

O TO

— f->

TO <W

1 §

U CO

^ .2

« a)
*> ^

Q ^
«H "to

8 1

H <q

n IN n

j Jj a

<
H
O
H

•2 fe

> ^

performing the calculation of "release" times, detecting potential conflicts, and
providing spacing control assistance to the Controller. The application of "signal-
ing" for Departures (release onto runway, release for takeoff) is also a significant
possible source of workload reduction.

With the LCS, therefore, it is estimated that the Controller's workload
would be reduced to between 50 percent to 60 percent of the present workload (on a
functional basis).

SECTION 6 - RELATED SUPPORT CONCEPTS

6.1 AUTOMATIC GATE STATUS EQUIPMENT (AGSE) CONCEPT

6.1.1 Introduction

The Automatic Gate Status Equipment (AGSE) concept is relatively
new to airport surface traffic control. The AGSE provides a means of coordi-
nation between the ATCT and airlines flight operations in the management and
control of aircraft movements, which heretofore has not existed.

The AGSE concept has been discussed to a large extent in Section 3
as an integral element of the Ramp Control System concept. It plays an im-
portant role in the Ramp Control System for the implementation of Positive
Ramp Control at airports requiring this capability. However, the AGSE con-
cept can be quite useful at those airports for which Positive Ramp Control is
not required. This importance derives from the reduction of controller-pilot
communications workload which may be achieved.

This section is devoted to a discussion of the AGSE concept in this
latter context. Reference to previous discussions in Section 3 will be made
where applicable to avoid unnecessary repetition.

6.1.2 Information Requirements Estimation

In an airport environment in which Positive Ramp Control is not
required, the requirements for AGSE stems from three basic information needs
of aircraft ground control. These are:

• Identification of the point of origination (terminal gate

or other portion of the airport ramp area) for departures
and other flights outbound from the passenger terminal(s).

• Identification of the destination (terminal gate or other por-
tion of the airport area) for arrivals and other aircraft in-
bound to the passenger terminal (s).

• Information on the availability of the destination gate for ar-
rivals and the extent of any delay in its availability.

• Information that the arrival aircraft arrived at and docked
or parked at their destination gate.

Knowledge of the point of origination is required for determination
and transmission of the routing of the departure to the appropriate departure
runway by (Outbound) Ground Control. The second data element is needed for
determination and transmission of the routing for other outbound flights to the
appropriate cargo /hangar area by (Inbound) Ground Control. The third is de-
termination of the position of the flight for reference in sequencing (control-
ling) the entry of the flight into the traffic flow on the taxiway network. The
fourth element (position of the flight) would be useful for initiation of automatic
surveillance and tracking of its movements in order to reduce the time for
search and acquisition by the surveillance subsystem.

Knowledge of the aircraft destination is similarly important for
routing of Arrivals or other traffic to the terminal building. Depending on the
airport runway-taxiway surfaces configuration and associated routing patterns
this data element may also be important in sequencing of these flights into the
traffic flow pattern.

Availability status of aircraft destination gates is also important
in the aircraft routing. When a flight's gate is not available it may be neces-
sary to route it to a holding area (e.g. , the Penalty Box at O'Hare). In addition,
since there may be several holding areas, the usage of these is dependent on
the destination gate of the flight and/or the amount of gate delay anticipated.
This, therefore, will also affect the routing of the aircraft.

Knowledge that aircraft have arrived at and docked/parked at their
destination gate is important for two reasons. The first is that when this oc-
curs the aircraft no longer represents any potential need for service by the
ATCT. Under certain conditions where the controller cannot visually observe

this event, explicit action to indicate its occurrence becomes neceessary. These
conditions could exist when controller visibility of the terminal ramps is blocked
due to the physical configuration of the terminal or other physical structure with
respect to the location of the ATCT. They could also exist under low visibility
operating conditions.

The second reason is that aircraft gate arrival data is a useful ele-
ment in maintaining gate availability status. This could eliminate the need for
direct coordination with airline flight operations for each arrival.

6.1.3 Functional Flow Description

The functional flow of the AGSE in airports not requiring Positive
Ramp Control is illustrated in Figure 6-1.

As in the previous Ramp Control System discussions the pre-filed
gate schedules and updates by airlines' flight operations personnel would be
maintained in the Gate Schedules File. This information would be utilized in
the generation of improved flight strips as previously discussed.

When an arrival flight is added to the Ground Control Arrivals Q
List by the Local Control System, a request for a gate availability for the
flight is received. The Gate Schedules file will then be accessed to determine
the assigned gate and its availability. A gate could be defined as available if
it was open or a departure on the gate has pushed back and called for taxi.

If the assigned gate is found to be available, the assigned gate
number and its availability would be transmitted to the Ground Control System.

If the assigned gate is not available a gate verification request would
be displayed to the appropriate airline's ramp controller. A revised gate as-
signment and/or gate availability delay would be entered by the airline's ramp
controller. This data would be transmitted to the Ground Control System and
would update the Gate Schedules data.

ENTER
FLIGHT DOCKED/
PARKED

GROUND

CONTROL

ARRIVAL

QUEUE LIST

From
Local
Control
Sys tern

Request for Gate

TRANSMIT
GATE No. AND
AVAILABILITY

TRANSMIT
GATE No. AND
AVAILABILITY
DELAY

TRANSMIT
FLIGHT GATE
ARRIVAL

* Control
► System

Figure 6-1. Functional Flow for AGSE in Airports Without
Positive Ramp Control

At a later time the flight's arrival at its gate would be reported by
the pilot to the airline's ramp controller (or observed by the ramp controller,
where the airline operates its own operations tower). This status report would
be entered by the airline's ramp controller. This would result in transmission
of an indication of gate arrival to the Ground Control System in order that the
flight could be deleted from the Active Aircraft List. It would also update the
Gate Schedules data.

6.1.4 Operational Requirements

The AGSE should possess sufficient capacity to meet the require-
ments for:

• Storage of Gate Schedules data

• Processing of all inputs updating this data base

• Display of gate availability requests at all airlines
installations

• Receipt, processing and transmission of response to
gate availability queries.

• Generation and transmission of gate arrival status to
Ground Control System.

At a minimum, sufficient capacity should be provided to meet all
requirements at the peak operations rate of the airport to avoid any delay in
the receipt, processing, and response to gate availability requests from the
Ground Control System. Under low visibility operating conditions it is likely
that changes to gate assignments and/or gate availability delays would increase.
The AGSE should possess sufficient capacity to handle the increased number of
data entries and display of gate verification. However, as the volume of traf-
fic operations is likely to be lower under these conditions the capacity for oper-
ation at the peak operations rate of the airport may be sufficient.

6.2 STANDARD TAXIWAY ROUTING MODULE

6.2.1 The Routing Communication Problem

Ground control procedures at O'Hare require that the Outbound
Ground issue to every departing aircraft a taxi route to the current departure
runway. Presently, this routing data is communicated to the pilot by the Out-
bound Ground Controller as part of Function B (Release of Departure A/C into
the taxi system), i.e., during the initial taxi clearance instruction. An example
might be:

"Eastern 114. Your runway is going to be 14 Right. Turn
right onto the Outer behind that DC 10 coming from your
left. Follow to the New Scenic and then up the Bypass to
the North West Parallel taxiway."

During busy traffic hours, communications are issued from Out-
bound Ground to the pilot in a more abbreviated format. This format permits
the controller to handle more aircraft without saturating his communication
channel. Thus the clearance example above is shortened to:

"Eastern 114, 14R, Outer behind the 10 to Scenic, Bypass to
North West taxi"

This abbreviated format requires greater pilot attention , since
there are fewer redundant words. He must know the O'Hare taxiway layout
better, since the route requires greater interpretation. Finally, the rapid mes-
sage rate can increase pilot misunderstandings of the selected route and control
instructions. Not all misunderstandings are pilot errors. In the above example,
the Northwest taxiway and the Northwest Parallel taxiway are at opposite ends
of O'Hare. Should the pilot take the "Old Scenic" instead of the "New Scenic"
in the abbreviated format example, runways 4L and 9L may be crossed before
the Outbound Ground detects the error.

A similar routing scenario occurs with arrival aircraft and the In-
bound Ground Controller. Here Inbound Ground must issue a taxi route to each

arrival aircraft. This routing data is communicated to the pilot by Inbound Ground
on the initial communications with the pilot after handoff from Local Control (at
start of Function E, Acceptance of A/C into Taxi System). Again, as traffic
increases, Inbound Ground will issue route and control instructions in an abbre-
viated format in order to prevent saturating his communications channel.

Safety incidents can occur when routing misunderstandings result
in aircraft crossing active runways or competing simultaneously for the same
piece of taxi pavement. The Standard Taxiway Routing module (STR) is pro-
posed to reduced this safety hazard as well as increase the Ground Controller's work-
load capability (number of aircraft handled).

6.2.2 Standard Taxiway Routing Considerations

At O'Hare, most departure taxi routing schemes are procedurally
established by parameters that are independent of Outbound Ground Controller
actions. These parameters such as gate position, departure runway, etc. , are
usually fixed and known well ahead of taxi clearance time. As such, detailed
departure routing can be correctly established, for most aircraft, minutes be-
fore taxi clearance requests are to be issued.

Similarly, arrival aircraft have established routing parameters
that are independent of Inbound Ground action. Again, these parameters such
as landing runway or gate/penalty box destination can be determined well ahead
of Local Control handoff. Thus, detailed arrival routing can also be established
several minutes before handoff.

The Standard Taxiway Routing module is proposed to perform the
establishment and issuance of standard taxi routing for all aircraft entering
the taxiway system. These are the five steps of the initial routing sequence
outlined in Figure 6-2. The STR module will eliminate the burden of detailed
routing responsibility on the two ground controllers and their communications
channels. Pilots could then receive their routing instructions in some other

PILOT
IDENT

OBTAIN

ROUTE

SELECTION

PARAMETERS

SELECT

ROUTE FROM

STANDARD

SET

ISSUE

ROUTE TO

PILOT

CONFIRMS

ROUTE

Aircraft Enters Taxiways

METHOD
RADIO

RADIO VISUAL GROUND CONTROLLER GATHERS PARAMETERS FROM VARIOUS SOURCES.
FLIGHT STRIPS EXAMPLES ARE AIRCRAFT TYPE, RUNWAY CONFIGURATION, IN-FLIGHT
OTHER RESTRICTIONS, GATE SOURCE OR DESTINATION, AND SO FORTH.
MEMORY PRO- GROUND CONTROL SELECTS ROUTES AND ALTERNATES FROM MEMORY
CEDURAL OF THE STANDARD ROUTES. THIS IS PREVIOUSLY ESTABLISHED PRO-
CRITERIA CEDURE.

Figure 6-2. Initial Routing Sequence of Inbound and Outbound Ground

manner and most likely prior to taxi clearance requests. Using STR, the
pilot and the Ground Controllers will both know the detailed routing scheme as-
signed to the aircraft. By adding a phonetic such as, "I've got STR Alpha", to
the initial Step 1 call, the pilot has performed Step 5, confirmation of the route.
The Ground Controller will only issue changes to the STR route (rare) as re-
quired for conflict resolution or required recent changes due to the runway,
taxiway, or terminal traffic control configurations.

6.2.3 STR Module Development Concepts

The STR module will develop in stages from an initial primitive
form until it is finally integrated into a fully automated taxiway routing control
system of later years. The initial stages of STR may be implemented with just
procedural changes. As such, the STR system will handle the bulk of the pre-
dictable routing now burdening the Inbound and Outbound Ground controllers.
The intent is to offload this burden onto the as yet unspecified STR techniques.

Possible methods of communicating the routing information to the
pilot include

1. The use of data links.

2. Issuance during the clearance delivery process. This may
require that confirmation of enroute clearance is handled
in a different manner than at present.

3. Use of billboard type signs at the gates.

4. ATIS type channels.

The STR module is not associated with a specific piece of develop-
mental hardware, but is part of the taxiway routing function (Function H) and
can be implemented by various methods. As the developmental hardware items
of the ASTC modules are installed, the STR module may be implemented with
this hardware and in later years it could be integrated into a fully automated
taxiway routing control system. Various stages of STR implementation will
result.

A criteria for the STR module design is to maximize payoff in terms
of increased safety, increased aircraft throughput rates, ability to operate ef-
fectively at lower weather minimums, and reduced controller communications
workloads. Events of lower probability, such as "pop-ups" or Cat IIIC capabil-
ity, may be excluded from STR unless their payoffs justify the increased costs
and complexity. It may be that some STR methods cannot implement satisfactory
taxi routing of arrivals since arrival routing is less predictable. For instance,
early or late runway turnoffs of arrival may result in different standard taxi
routes. Also, a gate status change or ramp pushback congestion can dynamically
alter arrival routing.

6.2.4 Functional Requirements Estimation

The following is an estimate of the functional requirements of the
Standard Taxiway Routing Module. As indicated in the previous paragraph,
STR is primarily a procedural module not associated with a specific hardware
item. The STR module is part of the taxiway routing function that deals with
the issuance of standard routes to all aircraft entering the taxiway system. Its
elements will be undergoing change as hardware is added, obsoleted or up-
graded in the ASTC systems. Thus, the STR module requirements, the result-
ing benefits, and actual implementation may be affected by each change in the
total ASTC system.

The functional requirements or elements of the STR module are
tabulated below and outlined in Figure 6-2.

1. Aircraft Identity

2. Acquisition of Route Selection Parameters

3. Route Selection Algorithm

4. Route Issuance

5. Pilot Confirmation

The necessity for aircraft identify depends on the particular type of
STR module. The ATIS broadcast type of STR Module would not require initial
aircraft identity. The advanced data link STR module would require aircraft
identify if it is to perform individual route selection and issuance.

The Route Selection parameters are the information inputs used by
Inbound and Outbound Ground Controllers to select a particular taxiway route
for arrivals and departures. Table 6-1 lists the major Route Selection param-
eters used by the O'Hare Inbound and Outbound Controllers in early 1974. The
list changes periodically as the airport layout and traffic control procedures are

Table 6-1. Route Selection Parameters

Routing

Selection Parameters

Affected

Controllers Source

Runway Configuration in Use

Both

ATC, local

Taxiway Configuration (Mainte-
nance/Obstructions)

Both

Visual, radio, other

Surface Origin and Destination

Both

Radio, visual, surveillance
sensors

Aircraft Type (747 Heavy)

Both

Part of A/C identity

Gate Status

Arrival

Visual, radio from Ramp
Control System

Penalty Box-Hold Points Status

Arrival

Visual, other

In Trail Restrictions*

Departure

Flight strip

First Fix*

Departure

Flight strip

*May impact on Surface Origin and Destination.

Eleven major runway configurations are identified in the Operation-
al Analysis report for O'Hare in 1974. Each configuration results in two or
more standard departure routes plus alternates. An STR functional require-
ment is to select the correct routes from these 70 or so standard routes. The
selection process or algorithm is based on the selection parameters. This re-
quirement can be a simple Flight Data Controller Table Look-up procedure or
it may be a program within a computerized automated routing control system.

The functional requirement for route issuance will be the STR com-
munication link to the pilot. At present, the Ground Controller half duplex par-
ty line radio channel performs this function. Any effective STR module will
have to develop a different link or method of communicating detailed routing
to the pilots. For the semi-automated ASTC system, it appears that VHF radio-
voice communications will be used exclusively. In the more advanced ASTC sys-
tems of later years, STR communications may be assisted by automated CGE
and/or VGE systems. As an example, a CGE cockpit/ tower data link with au-
tomatically switched control signs and lighting systems may be used for route
issuance. Costs and responsibilities for CGE and VGE systems will spread
across the airport authority, the air carriers, and the FAA causing great in-
ertia on speedy implementation. The present controller partyline single-
channel communications may be unacceptable for STR purposes due to such
hazards as a "stuck-mike" button or simultaneous transmissions by two or more
channel users. Discrete address-handshaking roles over a multichannel com-
munication link may be required for STR communications.

The pilot confirmation of the route is considered a necessary feed-
back control requirement. Without confirmation, the ground controller has no
positive assurance that the pilot has received the correct route. The present
use of partial confirmation is hazardous. Full confirmation by the pilot re-
porting back the detailed route may be necessary. This could be automated
with CGE items such as the Cockpit- Tower data link, but would saturate the
present Ground Controller communication channels.

SECTION 7 - SUMMARY OF SENSOR PERFORMANCE REQUIREMENTS

This section summarizes the estimates of performance requirements
made in the preceding sections of this report. In addition, the independent esti-
mates made by our subcontractor, Bendix, are also discussed.

If the Ramp Control System option is selected, it is recommended
that no attempt be made to obtain aircraft maneuver data (position, velocity, etc. )
on aircraft within the ramp area except for automatic transfer of VFRs and general
aviation IFRs to the Handoff to Ground Control Departure Q function (see paragraph
3. 2. 3. 1). Such automatic transfer will require resolution capabilities on the order
of 100 feet from aircraft center to aircraft center. In general, however, informa-
tion on aircraft position within the ramp area will be obtained via procedures using
AGSE (gate) data, estimates made from empirical data (using measured values of
pushback time, entry time, etc.) and inputs from the GCS.

The semi-automated GCS must provide surveillance data on all aircraft
on the taxi ways and runways since the latter are sometimes used for taxi purposes
when they are not in use for landing or departing aircraft. Surveillance data is not
required on aircraft entering staging areas or the Local Control Departure Q; air-
craft "track" will be suspended at these locations and reinstituted at a later time.
We estimate that the surveillance sensor(s) should provide the following capability
(all values shown except response time are one-sigma)

Position Accuracy 20-30 ft

Velocity Accuracy 2-3 fps

Directional Accuracy 10 degrees (for Turn Recognition)

Response Time 2-3 seconds

with a sample period of the same magnitude as the Response Time.

If velocity data is to be derived from position measurements, it is
estimated that a more stringent position accuracy will be required. This is esti-
mated to be about 10 feet. However, an alternative of higher sample rates (e.g. ,
10 samples/second) will relax this requirement back to 20-30 ft.

The estimates made by our subcontractor, Bendix, for the GCS are

Position ±50 feet

Velocity ±5 percent (about 2. 5 fps for

V = 30 knots)

Directional ±20 degrees

No response time values have been provided by Bendix.

Resolution requirements for the GCS are based upon physical charac-
teristics of the airport with the ability to resolve an aircraft on the Inner Circular
from one on the Outer as a limiting case. Resolution capabilities of about 200 ft,
from aircraft center to aircraft center, appear necessary.

The estimated sensor performance requirements for the semi-auto-
mated LCS must be given for airborne aircraft and for surface aircraft. The LCS
must provide airborne coverage out to 5 nmi from runway thresholds and ground
coverage of all runways as well as the entrance and exit links interfacing with the
runways. Resolution capabilities of the airborne area of the LCS are estimated
as 1000 ft in order to separate aircraft on parallel approaches and to distinguish
aircraft on different altitudes. In the ground position of the LCS, resolution capa-
bilities of about 200 ft should permit recognition of aircraft exiting the Local Con-
trol Departure Q area as well as resolution of aircraft on the runways from those
on the parallels.

The estimated performance requirements of the ground position of the
LCS (one-sigma values except for Response Time) are as follows:

Position Accuracy 20 ft

Velocity Accuracy 2-3 fps

Directional Accuracy 5-10 degrees

Acceleration Accuracy 1. 6 fps

Response Time 1-2 seconds

with a sample period of the same magnitude as the Response Time. As with the
GCS, if position is used to estimate velocity either a greater positional accuracy
(10 ft) or a higher position sample rate (10 samples/second) is required.

For surveillance of airborne aircraft, the estimated accuracy require-
ments of the LCS are

Position Accuracy 150 ft

Velocity Accuracy 8 fps

Directional Accuracy 15 degrees (Departure Routing)

Response Time 1-2 seconds

with a sample period of the same magnitude as the Respone Time.

The estimates provided by Bendix for the LCS are as follows:

Ground

Airborne

Aircraft

Position Accuracy

±30 ft

±100 ft

Velocity Accuracy

±2 percent

3 fps

Directional Accuracy

±10 degrees

±20 degrees

No response times have been provided by Bendix at this time.

The independent estimates of CSC and Bendix given above do not differ
significantly. Both companies recognize the significance of velocity for such pur-
poses as Movement Recognition as well as prediction. The need for some type of
"heading" (aircraft fuselage direction) or "course" (velocity vector orientation)
is recognized for such diverse purposes as Turn Recognition, Turnoff Recognition,
Departure Routing, Turn onto Runway, etc. The achievement of this capability
from a series of position measurements must be further investigated if the
necessary algorithms are to be developed and evaluated.

Combining the requirement of the GCS and the ground portion of the
LCS (since these can possibly be provided by one sensor subsystem) results in
the following composite requirements for surface aircraft:

Position Accuracy
Velocity Accuracy
Directional Accuracy
Acceleration Accuracy
Response Time

20 feet
2-3 fps
5-10 degrees
1.6 fps
1-2 seconds

with a sample period of the same magnitude as the Response Time.

If position is to be used for derivation of velocity and/or directional
data either a position accuracy of the order of 10 feet or a sample rate on the
order of 10 samples/second will be required.

APPENDIX A - CHARACTERISTICS OF THE TAXIWAY NETWORK

The taxiway network at O'Hare will be described in terms of links and nodes (or
intersections); it serves traffic primarily between the ramp exit/entrance nodes
and the runway nodes (Departure Q areas and runway turnoffs). The control of
port surface traffic (i.e. , the management of these taxi facilities) will be strongly
influenced by such physical characteristics of the network as link size (length) and
network connectivity. Other factors such as the active runway configuration, air-
craft equipment characteristics, and traffic loads must also be considered in the
control process.

The nodes at O'Hare, considering primarily the South side of the airport, may be
considered to fall into one of the following classes:

Ramp Nodes (R)
Inner Circular Nodes (I)
Outer Circular Nodes (O)
South Taxiway Nodes (S)
Runway Turnoff Nodes (Y)

The connectivity between these classes of nodes may be described in matrix format
as shown in Figure A-l; note that connectivity may exist only between certain classes
(i.e., no single link exists between any Inner Circular and South Taxiway nodes).
The diagonal entries in this matrix (I/I for example) represent "highways" while
the off-diagonal entries represent interconnecting links between the "highways",
or between the entry/exit modes and highways.

A representation of the flow of aircraft through these links and nodes is shown in
Figure A-2 for both Departures and Arrivals. Figure A-3 shows the taxiing process
for Departures in finer detail. The number of links traversed on the major arteries
varies from aircraft to aircraft; however, only a single interconnecting link (I/O,
O/S) of each category will normally be used in the taxiing process at O'Hare.

Ramp

Nodes

(R)

NODE (INI

Inner

Circular

Nodes

(I)

^ERSECTIOI

Outer

Circular

Nodes

(O)

*) CLASSES

South

Taxi way

Nodes

(S)

Runway

Turnoff

Nodes

(Y)

R/I

I/I

I/O

O/O

O/S

s/s

S/Y

Figure A-l. Connectivity Matrix for Node Classes
O'Hare Airport (South Side Only)

o /Hramp to _ T

, 5 ^ ^ INNER J £

> To North (I Node)
To

INNER TO
OUTER

i North I

a) DEPARTURES

Bridge
Other

I 1

DEPT.O
NODES

R/w

NODE

R/W
Crossing

R/W
Turnoff
Nodes

jH RUNWAY .
S^ TO SOUTH

r—

*""

SOUTH
LINKS

R/W
NODE

RUNWAY
TO SOUTH

•¥